7 ms·

Sure, okay, but there's two problems with that: 1) you have to trust the user to get that right, and 2) how do you know it's an actual hardware terminal and not

Sure, okay, but there's two problems with that: 1) you have to trust the user to get that right, and 2) how do you know it's an actual hardware terminal and not a terminal emulator?

leni536 3y ago
TERM is already used for determining color support. Not sure what terminals do without color support with color escape codes.
- hnlmorg 3y ago
  > TERM is already used for determining color support. It's one of many ways to determine colour support. And arguably the worst of all of the ways too. - $TERM This isn't intended to contain colour information, yet that's how it's often abused. Meaning a lot of applications are broken in non-xterm terminals if they happen to use the $TERM variable correctly - ANSI code: CSI 22 c (Send Device Attributes, ANSI color) This is the correct way to check for a device capability. But it requires more effort and knowledge of terminals than your average developer has. So is rarely supported by console applications. - $COLORTERM This is the modern day equivalent to the device capability API. But also isn't used often - $COLORFGBG This was the original env var intended to be used like $COLORTERM, but fell out of favour because, well, nobody bothered to read any docs. - $FORCE_COLOR This is an often used standard. Christ only knows why this one exists when we already have 3 other env vars being used this way. Another example of nobody bothering to read any docs - $NO_COLOR This is intended to do the opposite of the others and tell applications not to use colour. However even this is often ignored. ---- That's 6 different ways to check whether to colour output or not. Only one actual standard method and everything is only partially supported (if at all) in applications. Hence why applications then need a `--color` flag, which even that differs in support and syntax across different command line tools. And the "default" method you described, $TERM, actually breaks applications on alternative terminal emulators and hardware terminals -- that is unless they decide to announce themselves as `xterm` and in that case that environmental variable becomes entirely pointless because it has naff all to do with terminal listening. ---- > Not sure what terminals do without color support with color escape codes. They ignore them. ANSI escape codes are a pain in the arse to parse but there is at least a documented standard way to parse them. Anything that is a CSI (Control Sequence Introducer) sequence, and that includes SGR (Select Graphic Rendition) parameters like colour codes, start with `{ESC}[` and terminate with a character in the range of 0x40 to 0x7E. It's actually a little more complicated than that[1] but that's the gist of it. So you know what to print and what to ignore. There are other escape sequences too, the other big one being OSC (Operating System Command) and they're terminated `{ESC}\`, which is usually referred to as ST (String Terminator). That is unless you're xterm, and then you terminate OSC sequences with either ST or BELL (char 0x07). A lot of this makes more sense if you look at code rather than documentation. So I've made an effort to ensure my own terminal emulator's source code is as self-documenting as possible, eg[2] [1] https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_... [2] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1.go https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1...
charcircuit 3y ago
1) The user does not set TERM. 2) You keep track of a list of what TERM are hardware based that need this delay
- phone8675309 3y ago
  > You keep track of a list of what TERM are hardware based that need this delay How does this work for a terminal emulator? Say I'm using Kermit, and I'm using its VT100 emulation. My term would be VT100. So this delay would still be present because my terminal emulator is emulating the VT100, so looking at the TERM variable won't fix that.
  - charcircuit 3y ago
    If you set your virtual terminal to emulate a physical terminal it shouldn't be surprising that software treats your terminal as a physical terminal.
    - phone8675309 3y ago
      It shouldn't be but it appears that concept has eluded some of the commenters on this article.
- hnlmorg 3y ago
  1. It’s just an env var and users frequently do fiddle with it 2. That’s great in theory, but in practice a lot of software is written expecting TERM to contain, for example, xterm. The TERM env var is actually worse than HTTP User-Agent for fingerprinting. And for all the same reasons why User-Agent is a hot ball of mess. The way capabilities between different hardware terminals are usually detected is via special interactive ANSI escape codes. But there isn’t currently one to ask if the terminal is hardware or software.
  - charcircuit 3y ago
    >It’s just an env var and users frequently do fiddle with it If a user misconfigures what their current terminal is there isn't much that can be done. >but in practice a lot of software is written expecting TERM to contain, for example, xterm. It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed.

Sure, okay, but there's two problems with that: 1) you have to trust the user to get that right, and 2) how do you know it's an actual hardware terminal and not a terminal emulator?

leni536 3y ago

TERM is already used for determining color support. Not sure what terminals do without color support with color escape codes.

hnlmorg 3y ago
> TERM is already used for determining color support. It's one of many ways to determine colour support. And arguably the worst of all of the ways too. - $TERM This isn't intended to contain colour information, yet that's how it's often abused. Meaning a lot of applications are broken in non-xterm terminals if they happen to use the $TERM variable correctly - ANSI code: CSI 22 c (Send Device Attributes, ANSI color) This is the correct way to check for a device capability. But it requires more effort and knowledge of terminals than your average developer has. So is rarely supported by console applications. - $COLORTERM This is the modern day equivalent to the device capability API. But also isn't used often - $COLORFGBG This was the original env var intended to be used like $COLORTERM, but fell out of favour because, well, nobody bothered to read any docs. - $FORCE_COLOR This is an often used standard. Christ only knows why this one exists when we already have 3 other env vars being used this way. Another example of nobody bothering to read any docs - $NO_COLOR This is intended to do the opposite of the others and tell applications not to use colour. However even this is often ignored. ---- That's 6 different ways to check whether to colour output or not. Only one actual standard method and everything is only partially supported (if at all) in applications. Hence why applications then need a `--color` flag, which even that differs in support and syntax across different command line tools. And the "default" method you described, $TERM, actually breaks applications on alternative terminal emulators and hardware terminals -- that is unless they decide to announce themselves as `xterm` and in that case that environmental variable becomes entirely pointless because it has naff all to do with terminal listening. ---- > Not sure what terminals do without color support with color escape codes. They ignore them. ANSI escape codes are a pain in the arse to parse but there is at least a documented standard way to parse them. Anything that is a CSI (Control Sequence Introducer) sequence, and that includes SGR (Select Graphic Rendition) parameters like colour codes, start with `{ESC}[` and terminate with a character in the range of 0x40 to 0x7E. It's actually a little more complicated than that[1] but that's the gist of it. So you know what to print and what to ignore. There are other escape sequences too, the other big one being OSC (Operating System Command) and they're terminated `{ESC}\`, which is usually referred to as ST (String Terminator). That is unless you're xterm, and then you terminate OSC sequences with either ST or BELL (char 0x07). A lot of this makes more sense if you look at code rather than documentation. So I've made an effort to ensure my own terminal emulator's source code is as self-documenting as possible, eg[2] [1] https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_... [2] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1.go https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1...

charcircuit 3y ago

1) The user does not set TERM. 2) You keep track of a list of what TERM are hardware based that need this delay

phone8675309 3y ago
> You keep track of a list of what TERM are hardware based that need this delay How does this work for a terminal emulator? Say I'm using Kermit, and I'm using its VT100 emulation. My term would be VT100. So this delay would still be present because my terminal emulator is emulating the VT100, so looking at the TERM variable won't fix that.
- charcircuit 3y ago
  If you set your virtual terminal to emulate a physical terminal it shouldn't be surprising that software treats your terminal as a physical terminal.
  - phone8675309 3y ago
    It shouldn't be but it appears that concept has eluded some of the commenters on this article.
hnlmorg 3y ago
1. It’s just an env var and users frequently do fiddle with it 2. That’s great in theory, but in practice a lot of software is written expecting TERM to contain, for example, xterm. The TERM env var is actually worse than HTTP User-Agent for fingerprinting. And for all the same reasons why User-Agent is a hot ball of mess. The way capabilities between different hardware terminals are usually detected is via special interactive ANSI escape codes. But there isn’t currently one to ask if the terminal is hardware or software.
- charcircuit 3y ago
  >It’s just an env var and users frequently do fiddle with it If a user misconfigures what their current terminal is there isn't much that can be done. >but in practice a lot of software is written expecting TERM to contain, for example, xterm. It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed.