5 ms·

This depends on your definition of “print”. What if your stdout is not a TTY? Also, if your stdout is a TTY, but your terminal is not ANSI X3.64? You might b

• hnlmorg 2y ago
  > This depends on your definition of “print”. What if your stdout is not a TTY? If it’s not a tty then you don’t print the ansi escape sequences. Just like how every other well behaving command line utility works. > Also, if your stdout is a TTY, but your terminal is not ANSI X3.64? You might be able to look up the corresponding escape codes in terminfo based on $TERM (or simply use tput(1)), but the terminal might not even be able to perform those operations. What do you do then? This feels unnecessarily argumentative but I’ll humour you. Don’t use $TERM as your only method of fingerprinting a terminal. $TERM is as useless at determining terminal capabilities as the User-Agent string is for determining a web browser’s capabilities. That all said, the actual ANSI sequences needed to perform the UX I suggested has been standardised since the days of vt100. So even nearly every hardware terminal will support it. And if you do happen to be running an actual teletype, well you’re in a museum so your use case is very different. In terms of terminal emulators, most strive for xterm compatibility. And even those that don’t, will still support vt100 sequences. If they didn’t, then even things like readline (and thus Bash) wouldn’t work in their usual expected way. Sure, the “correct” way to use ansi escape sequences is to query terminfo. But in reality you can get away with hardcoding vt100 sequences for most things. Plus you’ll reduce overhead for your utilities for something that is guaranteed to be supported anyway. In fact perversely, you might actually improve portability because terminfo itself isn’t universal (plenty of non-POSIX systems support ansi sequences but don’t ship terminfo).
  • teddyh 2y ago
    > Sure, the “correct” way to use ansi escape sequences is to query terminfo. But in reality you can get away with hardcoding vt100 sequences for most things. This might be the worst advice I have seen in a long while. All the world is not a VAX, as the tenth commandment for C programmers clearly states. Also, you are quite wrong: Many programs are run with TERM=dumb in order to function via terminals with limited interaction capabilities, like via a Web page, or as a subprocess of an editor, like Emacs eshell.
    • hnlmorg 2y ago
      > This might be the worst advice I have seen in a long while. All the world is not a VAX, as the tenth commandment for C programmers clearly states. Name me some common terminal emulators that don’t support vt100. I’d genuinely be interested to know. But as someone who’s an author of a readline library as well as a relatively popular cross platform $SHELL, I’ve never ran into any issues assuming vt100 compatibility. I can tell you now, such a terminal isn’t still in use. And this is why I said: if you cannot guarantee vt100 compatibility then you’re likely working in a museum and thus have very different requirements. > Also, you are quite wrong: Many programs are run with TERM=dumb in order to function via terminals with limited interaction capabilities, like via a Web page, or as a subprocess of an editor, like Emacs eshell. I didn’t say $TERM isn’t used. I said it’s unreliable for determining terminal capabilities. Take a look at all the different terminal emulators, 99% of them report themselves as xterm. Now take a look at all the terminal multiplexers. Most of them report themselves as screen. Hardware terminals don’t even use env vars, instead they use ANSI escape sequences to describe terminal capabilities. This is why I compared the $TERM to the User-Agent string. Perhaps I should also add that I’ve written my own terminal emulator too. And part of that process meant pouring over specifications for various different terminals (hardware and software). So I do have some idea what I’m talking about ;)
      • teddyh 2y ago
        > I didn’t say $TERM isn’t used. I said it’s unreliable for determining terminal capabilities. You did say that every terminal has vt100 capabilities. But TERM=dumb does not, which is why some environments do set it that way. > Hardware terminals don’t even use env vars, instead they use ANSI escape sequences to describe terminal capabilities. Firstly, for physical (i.e. non-emulated) terminals, the environment variable is set by getty, who gets it from either /etc/inittab, or now possibly a systemd service setting. So TERM is supposed to always be set. Secondly, how would you know what escape sequences to send to query the capabilities, if TERM is not set? You can’t send VT100 escape codes blindly, because, again, TERM might be “dumb”.
        • hnlmorg 2y ago