Hacker News Reader

Comment by whartung | Hacker News Reader

You can't have "everything you wanted to know about terminals" with absolutely no mention of terminfo and (previously) termcap.

You don't necessarily need ncurses to have a portable smart terminal experience, but you do need terminfo.

ncurses magic relies on the lore stored in terminfo, which contains all of the obscure escape sequences and other information about the disparate world of terminals.

They're maintained as a combined package, but you don't need ncurses to drive the screen. You can get the codes yourself if that's what you want to do. You can use tput to make colorful labels in shell scripts.

While much of the world has moved on to the One Terminal running on the One OS, not everyone has.

View on HN

As the article states:

> being compatible only with ANSI-capable terminals is a feature, not a bug

Driving old hardware terminals (as opposed to terminal emulators) is a fun stunt, not something of actual modern value. Every modern terminal emulator supports ANSI escape sequences. Some features are supported by a subset of terminals, but you can either 1) probe for those features by asking the terminal, which some terminals support, or 2) try them and have graceful degradation if they're not supported, or 3) have configuration options to use them, or 4) don't use them.

For every one case in which terminfo allows you to support some obscure non-ANSI terminal, there are many many more cases where terminfo won't happen to have a definition of the user's terminal (or won't know all the capabilities of the user's terminal) and you'll have less functionality than if you just used ANSI escapes. This is especially true over SSH and similar.

> Every modern terminal emulator supports ANSI escape sequences

Is this true on Windows? My understanding is that quite a few TUI libraries don't have windows support.

This is true for the new Windows terminal, which is more-or-less xterm compatible.

You don't need terminfo until you need to redirect those fancy outputs to a file, or you see a lot of weird [M; in your CI logs, or your ssh session does not display full 256 colors, or you question why we don't have true images in our terminals when we have bitmap escape codes for decades now[1]. No terminal was created equal and never will. terminfo is about future as it is about the past.

Color ansi codes might be everywhere today, but that's no reason to disgrace terminfo, there are a ton of other features that need checking and are not universal.

[1]: https://en.wikipedia.org/wiki/Sixel

> until you need to redirect those fancy outputs to a file, or you see a lot of weird [M; in your CI logs

The application should be checking isatty by default, unless the user overrides that.

> or your ssh session does not display full 256 colors

I've most often seen this kind of thing because the remote end doesn't have the right terminfo entries for the local terminal.

> or you question why we don't have true images in our terminals when we have bitmap escape codes for decades now

Sixel, specifically, doesn't seem to have much support other than in xterm itself (as opposed to otherwise-xterm-compatible terminals). And other bitmap extensions are something that many terminals support autodiscovery for.

> No terminal was created equal and never will. terminfo is about future as it is about the past.

Part of the problem is that terminfo doesn't have much info about the future, as opposed to the past.

For going beyond terminfo, I think autodiscovery protocols would be a better future path.

Plus a lot of interesting things aren't mentioned in terminfo - bracketed paste, cursor shaping, synchronized output, ...

And even truecolor was added to it about 10 years after terminals started gaining support.

And many terminals just claim to be "xterm-256color".

>2) try them and have graceful degradation if they're not supported

Note: There are many cases where degradation isn't graceful. Many terminals on windows currently spew garbage on your screen if you send bracketed paste (alacritty, for instance).

>1) probe for those features by asking the terminal, which some terminals support

This requires waiting for a reply, which often isn't useful. E.g. if you want synchronized output, you want it from the very first paint (because that's when the terminal is most likely to still be resized, e.g. by a tiling window manager). So you would have to delay your startup until you've either gotten a reply or "enough" time has passed that you believe it's not supported.

Frankly, this is all a big mess and terminfo isn't very helpful, but we don't have a good alternative either.

TFA does mention terminfo at the very end:

> being compatible only with ANSI-capable terminals is a feature, not a bug, go the fuck away. terminfo is a fucking joke. nobody needs to target obscure dumb terminals (or smart terminals, for that matter) from 1983 anymore.

I don't have the expertise to opinion on this. But AFAICT most terminals that people still use[1] will self-report as xterm or xterm-256color so they'll only use the xterm escape sequences anyway.

[1] kitty is a notable exception. But it's rarely supported on preinstalled terminfo's, and manually adding them to all the remote servers that you access is a PITA.

I routinely use screen in VT100 mode to get basic keyboard escapes for consoles on custom hardware.

There is no need for the complexity of terminfo or termcap, because we have an ECMA/ANSI/ISO standard for terminal control. We have had it since before terminfo. ECMA-48 dates back to 1976. People have had 46 years to upgrade to standard-conforming terminals.

Terminfo is not a de jure standard, only de facto. It is not in POSIX.

POSIX specifies a tput command with exactly three operations: clear, init and reset.

Right here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t...

There is a Rationale section giving reasons for why terminfo wasn't standardized.

Bottom line: ECMA/ANSI is the real standard that can be used to drive a conforming terminal from any OS, without any special library other than basic I/O.

The ECMA family of terminal standards (ECMA-35/43/48) is less definitive than you might think. See https://news.ycombinator.com/item?id=31417563 for some details.

^ This

Also not just ECMA. The standard was ratified by ANSI X3.64-1979, ISO/IEC 6429, and FIPS-86 in addition to ECMA-48. The whole civilized world wants these codes (e.g. \033[A for UP) to be a standard. Because it makes console development blissful when you can ignore all the accidental complexity of curses and terminfo when you can just assume the terminal behaves sanely and isn't the leftover byproduct of bygone commercial rivalries.

I've found that tcell works pretty well across many different OS terminals.

https://github.com/gdamore/tcell

Reply on news.ycombinator.com