5 ms·

The article nor the comment section mention curses or the terminfo database, which makes me sad. Wanna read something about terminals and terminal control sequ

The article nor the comment section mention curses or the terminfo database, which makes me sad. Wanna read something about terminals and terminal control sequences? https://invisible-island.net/ncurses/terminfo.src.html https://invisible-island.net/ncurses/terminfo.src.html Disclaimer: i use a DEC VT520

account42 6y ago
Because just like the code page in locales, you should not need to care about terminfo if all you want to do is show some basic color. In $current_year it is OK to assume that the current terminal (if stdout/stderr is a TTY) can at least parse color escape sequences - if yours doesn't then create your own wrapper that strips them. Generally the way git does it should be considered best practice. If - 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.
- blueflow 6y ago
  The git approach here is not "not caring about terminfo", but delegating the caring (of the difficult parts at least) to another program, namely the pager. The default pager `less` depends on the information in TERM and the terminfo database, and it has to, since functions like toggling to the alternate screen buffer are not standardized per ansi.
  - account42 6y ago
    git works without a pager too. 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.
    - blueflow 6y ago
      Line editing is tricky enough that i would recommend a thing like the readline library, which in turn uses ncurses. Just for colored output alone, i agree.
112233 6y ago
In my horrible opinion, you can have a fairly portable terminal application without using the abomination that is libncurses, just straight escape codes / control sequences. 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
- ygra 6y ago
  > the exceedingly strange console that was in Windows 95 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.
- chasil 6y ago
  This is my korn-shell fragment that I use to set up color codes. Everything but the final print is posix-compliant (change it to a printf to run under bash). 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.'$N
  - JNRowe 6y ago
    This is one of the many cool things that zsh comes with out of the box. It ships an autoload-able colors¹ script that does largely the same thing as your fragment, but you know it available wherever zsh is. In 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/colors https://github.com/zsh-users/zsh/blob/master/Functions/Misc/... ² http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-zsh_002ftermcap-Module http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-... ³ http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-zsh_002fterminfo-Module http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-...
tyingq 6y ago
It seems like all the remaining terminals and emulators have gravitated to the same feature set so people just assume it doesn't matter? There was, at one point, a fair amount of really oddball terminals, like the Hazeltine 1500 that weren't VT1xx compatible. And they were at least minimally useful on a Unix box with terminfo/termcap.
- blueflow 6y ago
  In theory, yes. In practice, gravitating towards the same feature set doesnt imply that it will end up with the same sequences (code for the F1 key): # 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| 00000003
- gumby 6y ago
  > ...like the Hazeltine 1500 that weren't VT1xx compatible. Don'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.
  - tyingq 6y ago
    The VT52 predated the 1500, though I imagine there are earlier Hazeltines.
    - gumby 6y ago
      Indeed, both of these terminals were part of a Cambrian explosion of glass TTYs. 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).
- skissane 6y ago
  > It seems like all the remaining terminals and emulators have gravitated to the same feature set so people just assume it doesn't matter? 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/AccuTerm-8-User-Manual.pdf https://static.zumasys.com/zumasys/atfiles/manuals/8/AccuTer...
AkBKukU 6y ago
Having been recently delving into getting a TRS-80 DT-1 emulating a Televideo 910 working with Linux, I couldn't agree more. 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 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.
- cytzol 6y ago
  > And it's not like it's difficult to avoid hard coding 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.
  - slavik81 6y ago
    You'll also find a lot of Google search results for "tput: No value for $TERM and no -T specified". I wish it was as simple as just calling tput, but you need to write a bunch of logic anyway.
  - AkBKukU 6y ago
    > Using terminfo or ncurses requires an extra dependency with a clunky interface. 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.
naewonawonga 6y ago
I deeply regret that I only have one upvote to give.

account42 6y ago

Because just like the code page in locales, you should not need to care about terminfo if all you want to do is show some basic color. In $current_year it is OK to assume that the current terminal (if stdout/stderr is a TTY) can at least parse color escape sequences - if yours doesn't then create your own wrapper that strips them. Generally the way git does it should be considered best practice. If - 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.

blueflow 6y ago
The git approach here is not "not caring about terminfo", but delegating the caring (of the difficult parts at least) to another program, namely the pager. The default pager `less` depends on the information in TERM and the terminfo database, and it has to, since functions like toggling to the alternate screen buffer are not standardized per ansi.
- account42 6y ago
  git works without a pager too. 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.
  - blueflow 6y ago
    Line editing is tricky enough that i would recommend a thing like the readline library, which in turn uses ncurses. Just for colored output alone, i agree.

112233 6y ago

In my horrible opinion, you can have a fairly portable terminal application without using the abomination that is libncurses, just straight escape codes / control sequences. 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

ygra 6y ago
> the exceedingly strange console that was in Windows 95 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.
chasil 6y ago
This is my korn-shell fragment that I use to set up color codes. Everything but the final print is posix-compliant (change it to a printf to run under bash). 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.'$N
- JNRowe 6y ago
  This is one of the many cool things that zsh comes with out of the box. It ships an autoload-able colors¹ script that does largely the same thing as your fragment, but you know it available wherever zsh is. In 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/colors https://github.com/zsh-users/zsh/blob/master/Functions/Misc/... ² http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-zsh_002ftermcap-Module http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-... ³ http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-zsh_002fterminfo-Module http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-...

tyingq 6y ago

It seems like all the remaining terminals and emulators have gravitated to the same feature set so people just assume it doesn't matter? There was, at one point, a fair amount of really oddball terminals, like the Hazeltine 1500 that weren't VT1xx compatible. And they were at least minimally useful on a Unix box with terminfo/termcap.

blueflow 6y ago
In theory, yes. In practice, gravitating towards the same feature set doesnt imply that it will end up with the same sequences (code for the F1 key): # 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| 00000003
gumby 6y ago
> ...like the Hazeltine 1500 that weren't VT1xx compatible. Don'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.
- tyingq 6y ago
  The VT52 predated the 1500, though I imagine there are earlier Hazeltines.
  - gumby 6y ago
    Indeed, both of these terminals were part of a Cambrian explosion of glass TTYs. 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).
skissane 6y ago
> It seems like all the remaining terminals and emulators have gravitated to the same feature set so people just assume it doesn't matter? 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/AccuTerm-8-User-Manual.pdf https://static.zumasys.com/zumasys/atfiles/manuals/8/AccuTer...

AkBKukU 6y ago

Having been recently delving into getting a TRS-80 DT-1 emulating a Televideo 910 working with Linux, I couldn't agree more. 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 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.

cytzol 6y ago
> And it's not like it's difficult to avoid hard coding 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.
- slavik81 6y ago
  You'll also find a lot of Google search results for "tput: No value for $TERM and no -T specified". I wish it was as simple as just calling tput, but you need to write a bunch of logic anyway.
- AkBKukU 6y ago
  > Using terminfo or ncurses requires an extra dependency with a clunky interface. 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.

naewonawonga 6y ago

I deeply regret that I only have one upvote to give.