I think the parent poster's point was that the Linux console framebuffer renderer in particular, is not a particularly full-featured terminal in terms of the SGR sequences it supports. Which can be slightly unpleasant when you're stuck working in "text" (really, console framebuffer) mode in Linux for whatever reason.
(Which makes me wonder: is there a way to tell Linux to not use its own console framebuffer driver for displaying TTYs, but rather to instead spawn some userland libsdl binary and connect it to the raw framebuffer? If so, we could presumably just drop in a fully-featured terminal emulator to act as the Linux console.)
> is there a way to tell Linux to not use its own console framebuffer driver for displaying TTYs, but rather to instead spawn some userland libsdl binary and connect it to the raw framebuffer?
That's almost how frecon (and kmscon/systemd-consoled before it) works.
Cool, that's exactly the type of thing I was picturing.
Is this used or packaged in any major Linux distribution besides ChromiumOS? I'd like to try out living inside this for a while (probably in a fullscreened VM) but CrOS is a bit too restrictive/unfamiliar as a userland for me to want to attempt it there. I guess Crouton exists, but I'd be afraid that Crouton would add an additional layer of impedance-mismatch to the VT that isn't there when just using it raw (like the kind you get when using tmux-in-ssh-in-tmux.)
I seem to recall there being an fbdev-based terminal emulator that does just take over a VT, maybe it was this one: https://www.systutorials.com/docs/linux/man/1-fbterm/ but searches show a couple of possibilities.
I'm not sure how it works with systemd, but back in init land you could just replace the getty lines in /etc/inittab with whatever you wanted to use on that VT, or replace the default login command. What you wonder should be possible.
Source: Quite a long time ago I believed that the Linux framebuffer was the future of development, and spent a lot of time making animated bootup sequences, custom login screens, writing libraries (in collaboration with others) to make development easier without having to go into a "framework" like DirectFB, and using elinks (or was it links2?) for browsing and fbi for image and PDF viewing.
> Quite a long time ago I believed that the Linux framebuffer was the future of development
Hey, most of the Linux-based "retro portables" are running a pure "libsdl with Linux framebuffer backend" userland. So it was at least the future of something.
I did a little digging into the VGA text mode hardware interface and it'd be possible to do proper bold and italics support by loading a second font and reusing the line drawings (which shouldn't italicize) and block graphics (that shouldn't bold) for additional styled symbols. Computing bold is a simple matter of OR'ing a bit-shifted character and, for italics, you can shift the top third one bit to the right and the bottom third one bit to the left. We used to do that in the 8-bit era when having three bitmap fonts took too much disk space.
I believe it was links. It had numerous backends from what I recall, to include fb, X, and maybe even svgalib. I don't recall elinks supporting any of that. But I could be wrong.
I'd chip in a few bucks for a Patreon supporting someone patching that functionality into the Linux framebuffer console. I don't use Linux on a monitor right now, but typography deserves that chance, and much of my career is thanks to the Linux console.
My first paid programming job was making a client for a remote monitoring solution for the water industry. I must have been 14 or 15. One of my father's acquaintances knew I had been messing around with programming, and he needed a shiny Windows 95 application for his customers.
It would dial the plant via modem, and I remember being given a list of "escape codes" that determined how the stream of bytes should be rendered on the screen. My program parsed (some of) these codes and displayed the text accordingly, I specifically remember implementing the "move cursor" and "reverse mode" codes...
Not until years after did I realise I had basically built a shitty terminal emulator using Visual Basic text fields.
Take this gist with a grain of salt, many of the things listed there are NOT standardized by ansi, and some are specific to 16-bit real mode terminal emulators on the IBM PC or compatibles. I suspect this gist actually refers to the ANSI.SYS terminal implementation of MS-DOS.
If you want to have reliable and accurate information on how to control your terminal, consult the documentation on your terminal emulator or the ncurses database. The ncurses database is vast but does not include most of the exotic features of specific terminals.
[tl;dr] dont rely on secondary sources like this, please consult primary documentation instead
Specifically, relevant primary and reputable sources might include the ECMA-48 standard[1] (supposedly identical to the withdrawn ANSI one), the manuals for the various DEC VT-series terminals[2], the XTerm documentation already mentioned here[3], the detailed description of the VT100 state machine including how it fills the holes in the ECMA/ANSI spec[4], and maybe some compatibility tables[5]. There’s also a lot of folk wisdom beyond that, apparently, but nobody seems to have really gathered it in a usable form.
There is a Terminals WG over at the XDG[6], but I don’t know if they have produced anything useful yet.
FWIW, in a low-level cross-terminal API, I made up some concepts that seemed helpful (and there are also a few comments scattered in there, such as hints about why key mapping is less consistent than one would've guessed): https://www.neilvandyke.org/racket/charterm/#%28part._.Termi...
When discussing the possibility of implementing double width or height on VTE, someone did exactly that to finally settle how things behave. IIRC the same approach was used to find out what’s the “correct” way to do sixel graphics.
MS-DOSisms like the BIOS int 10h mode switch you mentioned in another comment are included, but so are things like (xterm) 256 color codes, TrueColor, and alternate screen switching, which IIRC were not a thing in ANSI.SYS. (The color thing I'm very sure because VGA text modes only supported 16 colors, the alternate screen mode is only a guess, it's very popular in unixy terminal emulators, but seems mostly useless for DOS.)
These escape sequences were known as ANSI long before the invention of ANSI.SYS. I suspect the standardization may be for the syntax and not the specific commands.
Playing around with BBSes as a teen, I'm super familiar with ANSI codes. I remember being fascinated by how they worked after opening up a .ANS file to see their contents.
One of my earliest programming projects was creating my own diary app which used ANSI codes to let you format the text. It also kept track of your cursor movements and encoded them so that you could do neat things like write text anywhere on the screen or overwrite existing text.
The first version of .sigs that I ever encountered were on BBSes that allowed ANSI codes in posts. I'm not sure which BBS software it was, but on at least one it was common for people to create fairly elaborate animations, slash-spinners, character flourishes, and other backspace-driven sequences for their message signoffs.
I still play around with BBS's but I have to look stuff up - funny thing about this new post was the external link has an 'visited' property unlike most stuff that comes across my feed because apparently I've landed on this github page a few times in the recent past... useful information!
I has a load of fun when I discovered this too, but eventually realised that a good cli app has focus, sensible use of opts, a succinct -h, reliable exit codes and above all easily parsed output on stdout.
I am all about sensible options, reliable exit codes, and easily parsed output on stdout--but easily parsed output on stdout when it isn't a tty is different from what you show a person when it is a tty.
It's also fairly straightforward to strip escape codes if you need to using sed or similar[0], and there probably already exists a tool that will do just that specifically and more robustly than my example.
For those interested in learning more about terminal emulators and character graphics, checkout Nick Black's book Hacking the Planet (with Notcurses): A Guide to TUIs and Character Graphics[1].
While the overall focus of the book is on programming with Notcurses[2], the author shares a wealth of related info and history throughout its pages.
It has some basic iTerm2 support too, so you can print out annotations in the console. Think of it like sticky notes.
See also ansi-styles, the lib that Chalk is based on. (Colors! You like colors? Are you a curmudgeony salt like me that refuses to use Rich for some reason? Use that.)
As with ansi-escapes, you can just pip install ansi-styles.
Or you can use curses (or ncurses, or any other terminal-independent library) like an adult, and not create yet another “works best in iTerm” application. We’ve been down this road before, and we settled on curses and similar libraries to be terminal-independent.
The 256 color palette was the most useful bit for me: not every terminal supports true color, and many terminals allow users to select color themes for the first 16 colors (e.g. "xterm -reverse"). So the upper 240 of the 256 color palette were the most reliable colors.
Here is a shell script to set and use colors. I added the truecolor functions just now.
#!/bin/dash
fg () ( printf '\033[38;2;%d;%d;%dm' "${1:-0}" "${2:-0}" "${3:-0}"; )
bg () ( printf '\033[48;2;%d;%d;%dm' "${1:-0}" "${2:-0}" "${3:-0}"; )
fg256 () ( printf '\033[38;5;%dm' "${1:-0}"; )
bg256 () ( printf '\033[48;5;%dm' "${1:-0}"; )
N='\033[' x=30
for a in Bl R G Y B M C W # Black Red Green Yellow Blue Magenta Cyan White
do eval $a='$N'"'"$(( x))"m'" \
b$a='$N'"'"$((60+x))"m'" \
${a}bg='$N'"'"$((10+x))"m'" \
b${a}bg='$N'"'"$((70+x))"m'" # bX=bright Xbg=background bXbg=brgt bgnd
x=$((1+x))
done
N=$N'0m'
printf "${B}${Gbg}This is blue on a green background.$N\n"
fg 255
bg 255 255 255
printf "This is red on a white background.$N\n"
x=0
while [ $x -lt 256 ]
do y=$((255-x))
fg256 $x
bg256 $y
printf "%.3d $N" $x
[ $(((1+x)%16)) -eq 0 ] && echo ''
x=$((1+x))
done
echo ''
Something i do way to much is `watch telnet <static-ip> 22` because it will print a Terminal bell and then i know a embedded device with a short ssh/dhcp window is up.
This is for dropbear ssh have not tested it on openssh, yet.
It also works with just the bare terminal line discipline in many flavours of unix: look at the 'lnext' control character in the output from 'stty' on Linux, macOS, or BSD (but not POSIX).
(however the equivalent in emacs itself is ctrl-Q, probably for bad reasons)
Back in the day, during the dorm wars, we would all have syslogd writing to terms to keep track on our nefarious neighbors in realtime. Echoing ANSI escape codes strategically was a good way to erase those tracks.
Search for both "vertical tab" and "VFU" (Vertical Format Unit). The "VFU" would accept commands to set the vertical tab stops to match whatever form you had. Say there was an address box that was 6 lines the top, a multi-line field 10 lines from the top, and an SSN field 15 lines from the top, and so on. You could program those tab stops and have a tractor feed of those forms loaded. Which would be easier programmatically than, for example, doing the math on how the length of text in some multi-line field in between those two would change the amount of line feeds you would need to send to land in the SSN field.
So, something like:
<vt> Enter the Address Stuff
<vt> Enter some amount of multiline text without having
to calculate how many lines it filled
I only recall seeing it used on line or dot matrix printers. You could scroll the paper down at the current cursor point (some how this was different from line feed, maybe some printers allowed the number of lines skipped to be configured).
this was posted why? considering comments here saying it's not reliable information and the number of comments on the gist itself from when it was initially posted months ago saying it needed forks to fix problems and clarify......
https://man7.org/linux/man-pages/man4/console_codes.4.html