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?
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_...
[2] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1...
2) You keep track of a list of what TERM are hardware based that need this delay
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.
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.
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
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.
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.
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’.
Ridiculous
But for people who have physical terminals, which I know is exceedingly small, there is no other option. Hence why the behaviour still exists.
If time is your only constraint then use a clear screen hot key or write a function and make it a single char, like the following:
function r {
printf '\033c'
}
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 feels to me like there a real lack of objectivity in this thread.
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.
That's the wrong question. Nobody has done that study because it's obviously bad to have 1 second delays that aren't needed!
Show me an independent study that proves a 1 second delay has no negative impact on productivity or satisfaction.
But I can see nothing further is going to be gained from this conversation so I'll end it here
I have to run it, tops, maybe once a day when a remote screen session gets disconnected.
I'd really like terminal emulators to support marking the default top of the scrollback so I don't lose the earlier history but still get the benefit of being able to easily find the start of a command, but I'm not aware of any terminal emulators having any features that do anything like that. So `reset` is the next best thing.
You can also emulate this behaviour in your shell using the prompt string. Which is something I see a lot of people do too.
You probably can’t do either of these things in the VSCode term that you like, but that term is shit.
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.