undefined | Better HN

0 pointsPennRobotics2y ago0 comments

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.

0 comments

2 comments · 1 top-level

phone86753092y ago· 1 in thread

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.

hnlmorg2y 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’.

j / k navigate · click thread line to collapse