Build your own Command Line with ANSI escape codes (2016)
lihaoyi.com
lihaoyi.com
Outputting raw escape codes and hope that they work is not how you do it. This is not how any reasonable library (or bash, or git, etc.) does it. These programs and libraries start with the $TERM environment variable to find out what terminal the user is using, and then use something like termcap(5) or terminfo(5) to look up what capabilities that specific terminal has, and what actual escape codes to output to get that effect. In reality, though, most regular programs delegate all this to a library, like ncurses.
(And also make sure not to output any terminal codes at all if the standard output is not a terminal, as in isatty(3) or tty(1).)
This way, you can check for and use modern cool stuff like sixels, but not use them if some user is using something older like XTerm or the Windows Console.
Even then it still leaves a lot to be desired. I'm not sure I can consider any of this to be truly reasonable.
https://github.com/kovidgoyal/kitty/issues/2773
https://github.com/kovidgoyal/kitty/issues/879
https://lists.gnu.org/archive/html/bug-ncurses/2018-09/msg00...
I have mixed feelings about this... Sometimes I feel young and reckless and want to just output whatever I need without checking $TERM. In practice, all modern terminal emulators are essentially xterm-256color compatible. If something breaks, the worse you get is some funny characters. Is that such a big deal? Much better than propagate the silly termcap/terminfo complexity.
By the way, xterm supports sixels since forever.
Maybe I've been lucky, but I've written plenty software that blindly shoots CSI's at the console and still haven't hit any snags. Especially convenient when the channel is unidirectional; curl ocv.me :)
If I remember correctly, ANSI-like terminal emulators in RGB mode (aka direct mode) only support 16-color and red/green/blue escape codes. Not the 256-color palette used in this article.
ANSI-compatible terminal emulators widely disagree on whether RGB values should be separated by semicolons or colons.
I have read articles (possibly on hackaday) this decade by people working on retro hardware projects, expressing frustration with command line programs that spew ANSI garbage to their non-ANSI terminals. At least one author resorted to the screen program, because it can translate some ANSI-isms to the correct codes for the active terminal.
I had genuine TeleVideo 912 glass terminals hooked up until not terribly long ago.
In any case, I don't view this as a matter of whether unusual terminals are "notable". We have an abstraction that plays nicely with them (and allows new terminal protocols to be developed). It's a POSIX standard. It's easy to use. I suggest using it.
(I'll put examples in a separate comment.)
See https://stackoverflow.com/questions/54838578/color-codes-for... for examples.
green=$(tput setaf 2)
normal=$(tput sgr0)
echo ${green}Color${normal} text.
...or if you plan to run on non-POSIX systems that lack tput...
green=$(tput setaf 2 2>/dev/null || true)
Also not mentioned in the article: there are a few syntaxes available for specifying things in control sequences, like
\x1b[38;2;{r};{g};{b}m
for specifying colors. There's a nice list here: https://gist.github.com/ConnerWill/d4b6c776b509add763e17f9f1... You can also cram as many control codes as you want into a control sequence, though it probably isn't useful in a modern context in 99.9% of cases.