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.
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'
}
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.
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.