Wanna read something about terminals and terminal control sequences? https://invisible-island.net/ncurses/terminfo.src.html
Disclaimer: i use a DEC VT520
Main reason is that most of current terminal emulators are actually xterm emulators: they support a good subset of xterm features. Also, the exceedingly strange console that was in Windows 95 is finally out. What quirks and differences are left, can easily be detected at runtime, no need for $TERM and terminfo/termcap
N='\033[' x=30
for a in Bl R G Y B M C W # 4-bit 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
done
N=$N'0m' x=0
print $bB'This is bright blue.'$NIn much the same way it comes with both a termcap² and terminfo³ module, allowing you to easily avoid hardcoding system specific escapes in to your config.
¹ https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
² http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-...
³ http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-...
We made two decisions early on: xterm is the only terminal protocol, and UTF-8 is the only encoding. This has spared us unending amounts of pain, because we don't abstract over these things. There is a bit of divergence between xterm implementations, but for what we do, not much: if you want to print images there are a few strategies, none of them universal, and the closest (sixel) isn't great imho.
We've also found that, with a modern terminal, a lot of what curses brings to the table isn't necessary. While we did divide the terminal up into zones, and only repaint changed zones, we shouldn't have bothered: as long as you hide the cursor when you start a paint, and show it after you put it back, filling the entire screen with a complex/colorful xterm pattern happens within one refresh, so no flicker.
There is certainly no need to calculate a minimal delta change and only print that, on a reasonably modern system (anything from the last ten years will do).
That only ever tried to be a terminal emulator when ansi.sys had been loaded. But it's been gone for quite a while now. The Windows console host on the other hand only gained terminal emulator capabilities in somewhat recent Windows 10 versions.
There is no reason to use terminfo or libncurses in 2021.
They were created specifically for the Lear Siegler ADM-3A, which predates the VT100. The work was done entirely by Bill Joy, who later joined Sun Microsystems.
In the context of Unix-like systems, that is pretty much true. But, broader than that context, there are still terminal emulators in use which are completely unrelated to DEC VT. People still use IBM 3270 emulators to talk to IBM mainframes, and IBM 5250 to talk to IBM i (formerly known as OS/400). People still use Unisys T27 terminal emulators to talk to Unisys mainframes.
There are also some terminal emulators out there with unusual features. Consider AccuTerm, a terminal emulator specifically designed for use with PICK systems. If you read page 207 onwards of [0], you will see escape sequences to display images, run commands on the client machine, trigger file uploads and downloads, and even a facility for an escape sequence to embed a VBA script which is then executed. A lot of that is quite dangerous if you don't trust the system you are connecting to, or if the system you are connecting to doesn't correctly filter escape sequences out of untrusted data; but, assuming it does, it can be used to easily create some integrations between legacy PICK apps and Windows desktop apps such as Microsoft Office.
[0] https://static.zumasys.com/zumasys/atfiles/manuals/8/AccuTer...
# for i in linux rxvt-unicode xterm; do TERM=$i tput kf1 | hexdump -C; done
00000000 1b 5b 5b 41 |.[[A|
00000004
00000000 1b 5b 31 31 7e |.[11~|
00000005
00000000 1b 4f 50 |.OP|
00000003Don't forget the 1500 came out before the VT100.
Your comment is a reminder of how dominant DEC was at the time, the Apple to IBM's Microsoft.
I mentioned the VT100 specifically as that was what the comment referred to. Also because for some reason it somehow became iconic, though I don't know why (I always thought the VT52 superior, though the best IMHO was the Ann Arbor Ambassador).
- Output is a TTY
- The NO_COLOR environment variable is not defined
- The TERM environment variable is not set to "dumb"
then enable colors by default.
I agree that you will need something like terminfo if you writing a TUI like a pager, but for most CLI programs you only need simple color output and maybe cursor movement on and erasing of the current line and for that terminfo is an unnecessary dependency.
Just for colored output alone, i agree.
Even now for modern devices it wouldn't be the worst idea to avoid hard coding things like color (e-ink?). And it's not like it's difficult to avoid hard coding, using tput ( https://linux.die.net/man/1/tput ) means you don't have to write out the arbitrary escape sequences yourself while being compatible with any terminal.
"My team writes a lot of command line tools" is a valid excuse for internal use. But not for writing a educational post.
There are upsides to hard-coding the escape sequences that you aren't mentioning. Using terminfo or ncurses requires an extra dependency with a clunky interface. Using tput requires spawning a process, which gets slow if you have to do it repeatedly. But simply hard-coding the escape sequences is dependency-free, as fast as printing, can be done in any language, and is going to work for at least 99.9% of the users out there.
I'm usually a big fan of "use a standard interface rather than one particular implementation", but I haven't found a solution, other than hard-coding the ANSI escape code set, that I'm happy with.
Are there any linux distros for any platform that aren't shipping terminfo? I could see some embedded systems cutting it down for small storage solutions. But I don't think it's unfair to assume that terminfo is installed. ncurses is more complex so I won't disagree with that one, but tput isn't part of ncurses.
Clunkiness is an opinion, I see needing to look up what "\x1b[7m" means as being clunky compared to "tput rev".
> Using tput requires spawning a process, which gets slow if you have to do it repeatedly.
If you're pretty printing text for a human to read then I don't think the couple extra ms it will take to spawn a handful of tput processes is going to be an actual performance concern. If you're logging data that's another thing, but this was specifically about CLI programs.
> can be done in any language, and is going to work for at least 99.9% of the users out there. > I haven't found a solution, other than hard-coding the ANSI escape code set, that I'm happy with.
This is most likely true and I don't disagree that my stated use case is in the 0.01%. I was going to refute the any language comment with libraries based on terminfo, but all the ones I ran across in 30 seconds just hard code the ANSI escape sequences. Since it will likely work 99.9% of the time, it is "easy" in a way to hard code them. So I understand why it is being done that way and why you would also prefer to hard code them. But there is a standard interface to use, it just may not be perfect.
This may be something where we are technically stuck between a rock and a hard place. We have a good resource database of technical information on how to format text. But there isn't a significant reason to put in the effort to use it.
Ah, I was referring to higher-level languages such as Ruby here (I have a lot of scripts where I use it a shell script replacement) rather than C, where you can just download a compiled version and use it without any fuss. Ruby moved its curses interface out of the standard library a long time ago, so now you have to add it to your gems list.
> If you're pretty printing text for a human to read then I don't think the couple extra ms it will take to spawn a handful of tput processes is going to be an actual performance concern.
For scripts, I agree — I used to use tput, and only stopped because I'd eventually seen the ANSI escape codes enough time to just memorise them. But I find that if your program needs to use enough colours (my software has been called "overly colourful" before), the time it takes to run a tput once for every bold and normal variant of all eight colours quickly makes it seem like your program is running on the JVM, even if I cache the output. I appreciate that not all software needs every terminal style available to it, but it seems to me that the best interface should be able to scale to many styles, not just a few.
> I was going to refute the any language comment with libraries based on terminfo, but all the ones I ran across in 30 seconds just hard code the ANSI escape sequences.
This doesn't surprise me! I used to be concerned with the growing number of comments and guides on the internet that say things like "this is how you do bold in a terminal" as though it applies to all terminals, so I asked a question on Stack Exchange a while ago:
https://unix.stackexchange.com/questions/548158/in-2019-is-i...
I was hoping to find an answer from someone like yourself, who regularly works with non-ANSI terminals and was becoming increasingly annoyed at the proliferation of standards-shirking shell scripts... but I only got comments saying I was doing it wrong, as though I was the only one who didn't get the memo. You're the only obscure terminal user I've ever talked to in the wild, congratulations.
Anyway, I agree that we're stuck in this situation, and even though I am taking the easy way out, I still find that a shame.
That sounds very familiar. I swear some guy put a video up on Youtube attempting the same thing. :)
Love the channel. Keep the videos coming.