4 ms·

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 contai

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.
- hnlmorg 3y ago
  > If a user misconfigures what their current terminal is there isn't much that can be done. We aren't talking about people misconfiguring their terminal. We are talking about application developers abusing the $TERM command to detect terminal functionality rather than using ANSI escape sequences to detect a terminals support. And thus people then need to spoof $TERM strings to retain the same functionality. This is why you often see $KITTY, $MXTERM and other env vars in addition to $TERM. source: I wrote my own terminal emulator. $TERM these days is garbage. > It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed. New terminal emulators do. Plus we already have ANSI escape sequences for detecting terminal functionality and it was purposely designed for hardware terminals in mind. Just doing the kids school run but I can share a link to them when i return
- PennRobotics 3y ago
  From my experience, the list of new terminals IS always growing. Wayland? A developer wanting to flex their Rust or Go muscles? Poor Unicode or RTL support? Slow buffer? "I can GPU accelerate the terminal"? Tiling? Dropdown on tilde? Keypress customization? Better cross-platform compatibility? Sixel support? "We're a trendy yet ancient mega-corp that now supports open source please use our cloud product"? ... all reasons I've seen a new terminal or three. Last night, I ssh'd into a server that had a huge TERM list but alacritty was not on it, so I had no dircolors even when using --color=always. The only reason I'm even using alacritty is due to my last terminal not working well on new hardware. I don't have a better solution. Obviously the terminal should self-report its capabilities and everyone writes software respecting those, but that ship has sailed, so we're stuck with QWERTY as a keyboard layout (or whatever your country collectively uses; FR, DACH, etc), x86 as an architecture, and TERM as a variable.
  - phone8675309 3y ago
    You're missing a vital point here due to the overloaded nature of the word 'terminal'. The number of HARDWARE terminal types is not growing rapidly - few people are putting out new serial terminals where the TERM variable is intricately tied to the functionality of the terminal (and in many cases, even hardware terminals can emulate a few well known terminal types). The software you're talking about are terminal EMULATORS. They emulate the functionality of a hardware terminal, interpreting the escape sequences emitted by the software they're running in order to refresh a user display. You can have many, many new terminal emulators created without needing a new terminal list entry if they are emulating existing terminals. So let someone create 100,000 new Wayland terminals - they're likely going to be emulating vt100 or some variant of xterm. They don't need their own terminal entries.
    - hnlmorg 3y ago
      TERM is meant to apply to hardware and software (emulated) terminals. But in reality a lot of application software just looks for the string “xterm-256color” to decide if it’s a modern terminal or not. The problem is that I’ve seen applications even drop basic VT100 features if a $TERM doesn’t contain ^xterm. Which is insane. And all of this is using the wrong tools for detecting terminal capabilities because the old hardware terminals couldn’t define environmental variables for the host running the shell. In fact a lot of hosts didn’t even run UNIX, never mind have the concept of environmental variables. So there are ANSI escape sequences that request the terminal to reply (with a similar escape sequence) what that terminals capabilities are. That’s how termcap and other responsible tools work, and thus how ‘reset’ would also need to work given it is a symlink to ‘tget’ Env vars are definitely convenient in the modern era of operating systems and terminal emulator so I do understand why people lean on them. But the problem is they’re not standardised. So you get different people using different vars (like $TERMCOLOR $TERMCRGB $NO_COLOR $TERM $KONSOLE $KITTY etc) all for overlapping concerns. It’s a fucking mess because developers either didn’t read the manual, or have to support other developers who didn’t read the manual. So this is why I’m against using ‘reset’ using $TERM to detect device capabilities. This is also why my own terminal emulator, despite not being related to xterm at all, identifies itself as xterm in $TERM. It sucks that I have to, but that’s just how it is. The next question is whether ‘reset’ should even be the place for this code. I’d argue not because the requirement isn’t to reset the terminal, it’s to clear the scrollback. So the place for this change is ‘clear’, not ‘reset’.
IshKebab 3y ago
So you're advocating inflicting an annoying delay on tens of thousands of people because there might exist one person a) uses ancient hardware and b) uses recent software and c) messes with their TERM environment variable? Ridiculous
- zaxomi 3y ago
  Every change breaks someone's workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
  - IshKebab 3y ago
    So we should never change anything. Got it.
    - hnlmorg 3y ago
      You can change it though. Several people in this conversation have suggested ways to make that change. What you're asking is different. You want to make a global change to a core application in ways that are incompatible with existing, albeit extremely old, hardware. And the only justification is to speed up a non-standard use case for said tool. And you're pushing for this despite there already being purpose designed solutions to your exact problem. Linux (and GNU in general) frequently makes breaking changes. Like dropping 386 support. But it's done where there are actual real world problems. Like maintainability. Or security (why certain features were dropped from GNU Bash ~10 years ago). I get this delay is annoying for you but it's literally just a 1 (one!!) second sleep: (void) napms(1000); If 1000 milliseconds is that valuable to your productivity then why are you wasting millions of them arguing with strangers on the internet? If feels to me like there a real lack of objectivity in this thread.
      - IshKebab 3y ago
        > If 1000 milliseconds is that valuable to your productivity then why the hell are you waste millions of them arguing with strangers on the internet? Yes it is that valuable to me, because it isn't a single 1s delay. I endure it many times per day (or I would if I didn't fix it for me). And of course you know that little delays cost more than their "raw time" because they interrupt flow. And I'm arguing with people on the internet about it because 1. It's fun to argue with people who are obviously wrong, and 2. I care about other people and I would like them to not have to endure this idiotic paper cut.

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.

hnlmorg 3y ago
> If a user misconfigures what their current terminal is there isn't much that can be done. We aren't talking about people misconfiguring their terminal. We are talking about application developers abusing the $TERM command to detect terminal functionality rather than using ANSI escape sequences to detect a terminals support. And thus people then need to spoof $TERM strings to retain the same functionality. This is why you often see $KITTY, $MXTERM and other env vars in addition to $TERM. source: I wrote my own terminal emulator. $TERM these days is garbage. > It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed. New terminal emulators do. Plus we already have ANSI escape sequences for detecting terminal functionality and it was purposely designed for hardware terminals in mind. Just doing the kids school run but I can share a link to them when i return
PennRobotics 3y ago
From my experience, the list of new terminals IS always growing. Wayland? A developer wanting to flex their Rust or Go muscles? Poor Unicode or RTL support? Slow buffer? "I can GPU accelerate the terminal"? Tiling? Dropdown on tilde? Keypress customization? Better cross-platform compatibility? Sixel support? "We're a trendy yet ancient mega-corp that now supports open source please use our cloud product"? ... all reasons I've seen a new terminal or three. Last night, I ssh'd into a server that had a huge TERM list but alacritty was not on it, so I had no dircolors even when using --color=always. The only reason I'm even using alacritty is due to my last terminal not working well on new hardware. I don't have a better solution. Obviously the terminal should self-report its capabilities and everyone writes software respecting those, but that ship has sailed, so we're stuck with QWERTY as a keyboard layout (or whatever your country collectively uses; FR, DACH, etc), x86 as an architecture, and TERM as a variable.
- phone8675309 3y ago
  You're missing a vital point here due to the overloaded nature of the word 'terminal'. The number of HARDWARE terminal types is not growing rapidly - few people are putting out new serial terminals where the TERM variable is intricately tied to the functionality of the terminal (and in many cases, even hardware terminals can emulate a few well known terminal types). The software you're talking about are terminal EMULATORS. They emulate the functionality of a hardware terminal, interpreting the escape sequences emitted by the software they're running in order to refresh a user display. You can have many, many new terminal emulators created without needing a new terminal list entry if they are emulating existing terminals. So let someone create 100,000 new Wayland terminals - they're likely going to be emulating vt100 or some variant of xterm. They don't need their own terminal entries.
  - hnlmorg 3y ago
    TERM is meant to apply to hardware and software (emulated) terminals. But in reality a lot of application software just looks for the string “xterm-256color” to decide if it’s a modern terminal or not. The problem is that I’ve seen applications even drop basic VT100 features if a $TERM doesn’t contain ^xterm. Which is insane. And all of this is using the wrong tools for detecting terminal capabilities because the old hardware terminals couldn’t define environmental variables for the host running the shell. In fact a lot of hosts didn’t even run UNIX, never mind have the concept of environmental variables. So there are ANSI escape sequences that request the terminal to reply (with a similar escape sequence) what that terminals capabilities are. That’s how termcap and other responsible tools work, and thus how ‘reset’ would also need to work given it is a symlink to ‘tget’ Env vars are definitely convenient in the modern era of operating systems and terminal emulator so I do understand why people lean on them. But the problem is they’re not standardised. So you get different people using different vars (like $TERMCOLOR $TERMCRGB $NO_COLOR $TERM $KONSOLE $KITTY etc) all for overlapping concerns. It’s a fucking mess because developers either didn’t read the manual, or have to support other developers who didn’t read the manual. So this is why I’m against using ‘reset’ using $TERM to detect device capabilities. This is also why my own terminal emulator, despite not being related to xterm at all, identifies itself as xterm in $TERM. It sucks that I have to, but that’s just how it is. The next question is whether ‘reset’ should even be the place for this code. I’d argue not because the requirement isn’t to reset the terminal, it’s to clear the scrollback. So the place for this change is ‘clear’, not ‘reset’.

IshKebab 3y ago

So you're advocating inflicting an annoying delay on tens of thousands of people because there might exist one person a) uses ancient hardware and b) uses recent software and c) messes with their TERM environment variable? Ridiculous

zaxomi 3y ago
Every change breaks someone's workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
- IshKebab 3y ago
  So we should never change anything. Got it.
  - hnlmorg 3y ago
    You can change it though. Several people in this conversation have suggested ways to make that change. What you're asking is different. You want to make a global change to a core application in ways that are incompatible with existing, albeit extremely old, hardware. And the only justification is to speed up a non-standard use case for said tool. And you're pushing for this despite there already being purpose designed solutions to your exact problem. Linux (and GNU in general) frequently makes breaking changes. Like dropping 386 support. But it's done where there are actual real world problems. Like maintainability. Or security (why certain features were dropped from GNU Bash ~10 years ago). I get this delay is annoying for you but it's literally just a 1 (one!!) second sleep: (void) napms(1000); If 1000 milliseconds is that valuable to your productivity then why are you wasting millions of them arguing with strangers on the internet? If feels to me like there a real lack of objectivity in this thread.
    - IshKebab 3y ago
      > If 1000 milliseconds is that valuable to your productivity then why the hell are you waste millions of them arguing with strangers on the internet? Yes it is that valuable to me, because it isn't a single 1s delay. I endure it many times per day (or I would if I didn't fix it for me). And of course you know that little delays cost more than their "raw time" because they interrupt flow. And I'm arguing with people on the internet about it because 1. It's fun to argue with people who are obviously wrong, and 2. I care about other people and I would like them to not have to endure this idiotic paper cut.