> Do you still need terminfo? It depends. If you just want to style some text and maybe do some basic cursor operations: probably not. If you want to use more advanced operations or read key input: probably yes.
I disagree. The vast majority of terminals will send the same sequences. There is almost never a case where handling the two options for backspace the same way will result in a bad user experience. What complicates this even more is that many terminals allow the user to modify which sequence the `Backspace` key sends (0x08 vs 0x7F). Any application relying on terminfo, where a user did not modify their terminfo entry, will interpret these wrong if a user has manually changed it.
Terminfo is not needed anymore. It served a purpose to let applications know how to talk to a terminal. That era is gone.
> Key input handling is kind of a mess, and this is where I really recommend using a terminfo library if at all possible. This also avoids the whole backspace/delete key confusion (less of an issue today than it used to be, but still exists).
Of course lots of applications don't use backspace or delete; sometimes you just want the ability to select between 3 items with j/k and arrow keys, or something like that. And if this is something just for yourself or a limited audience then it's fine to just read that from stdin and not worry too much.
you are replying to a comment which specifically explains why it disagrees with the text you quoted from your essay; what is the point of repeating it?
if someone found it unconvincing the first time, or found rockorager's rebuttal to it convincing, hopefully a mere repetition of your comment will not change that. and, if they found it convincing the first time and found rockorager's rebuttal unconvincing, repeating it is unnecessary
I guess my point is that even for key input, you don't need terminfo. Modern terminals, and I would agree with your definition of that, all use the same keyboard encodings. There is the notable case of backspace/delete you mentioned but as I said - you can treat both as a backspace press.
All of that said, I am a huge proponent of the kitty keyboard protocol. I would love to live in a world where the "default" encoding of keys is done with the that protocol (with the disambiguate flag on)
> I guess my point is that even for key input, you don't need terminfo.
Right, I read that the other way round ("no, you do need terminfo for key input")!
For basic input it's fairly straight-forward, and even for various "special" keys like arrows and function keys it's not too bad: just check from a list.
But with modifier keys it gets more tricky; lots of that isn't even in terminfo
and requires "special" handling.
If you know how this works and you know what you're doing it can be fine, but for most people it's far easier to just use a terminfo library that does this for you.
And yeah, Kitty keyboard protocol being the default would be brilliant. Right now support is (far) too flaky though, so maybe in 5 to 10 years.
Gotta admit I still have ptsd from working with a company that invested big in WYSE terminals early on. We were trying to switch over to terminal emulators and really wanted to just use one of the myriad of vt100 emulators avialable. Every single day was a different variant of "wtf is this. I wish they had just used terminfo"
So I don't know how needed it is anymore. But I will have a hard time giving up terminfo and going over to the darkside.
Agreed. I never understand the argument that we should forget that we solved a problem.
Most terminals today are mostly vt-like? So the F what?
Whether anyone likes it or not, or beleives it or not because of their own limited direct personal experience, the problem that termcap/terminfo worked around still exists today.
Since the problem still exists, the solution (or I would call it more of a work-around) is still required. Simply pretending or ignoring doesn't resolve anything.
When some spec becomes a decreed standard that you can actually count on, like we take one of the many vt-alikes and enshrine that one and all terminals are actually required to impliment that spec exactly, then you can maybe talk about "we don't need termcap or terminfo any more, it's ok to hard-code this spec from now on"
And I won't even start on all the things wrong with "just map both to up arrow" holy cow.
i mostly agree. if you want to run an application that assumes ansi escape sequence support and a terminal emulator that doesn't implement ansi escape sequences, you can run a terminal emulator inside your terminal emulator, with the inner terminal emulator interpreting the ansi escape sequences and talking to the outer terminal emulator with whatever escape codes the outer one uses
three options for this inner terminal emulator are gnu screen (previously iscreen, which was a better name), tmux, and emacs term-mode. all three of these can use terminfo to figure out how to manipulate the outer terminal—but they wouldn't have to. mosh also does this terminal-emulator-inception thing but i think it's hardcoded to use ansi escape sequences to draw
— ⁂ —
what i'd really like to see is a reimagining of the terminal interface as something better than a vt340+. we have lots of historical things that could be sort of described that way (genera's lisp listener, the blit, mgr, caleb winston's stdg, notty, x11, postscript, html, react, wayland, opengl, vulkan, vnc) but they all fall short in one way or another. minimally i want a user interface that i can
1. write programs for in any programming language such that
2. simple programs like 'hello, world' or displaying a two-column table of numbers are about as simple as in an xterm, and
3. the programs' input and output is manipulable by the user at various levels of abstraction (copy/paste, screenshots, editing the output text, automating interactive workflows (like expect/autohotkey/selenium), screen readers, asciinema/screencasting, livestreaming, obs studio), and
4. the program is interactive (html kind of fails at this), and
5. the user interface can be used on a separate computer from the program (maybe the user interface runs on a cellphone while the program runs on a rack in a data center, or maybe the user interface runs on a laptop while the program runs on a quadcopter), and
6. small computers (under a megabyte of ram) can be used to show the program's user interface, but
7. the program can display anything the user's monitor is physically capable of displaying and support any of the user's input devices, including mice, touchscreens, accelerometers, cameras, etc.
emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video
obviously there's some degree of tradeoff in some cases between 5, 6, and 7, because you aren't going to stream 4k video over a 9600-baud serial line, and you aren't going to decode it on a 286 (nor are you going to stream webcam video back from the user if the webcam is plugged into a 286), but there's a pretty broad spectrum today of {comms bandwidth, terminal cpu, desired output} triples for which performance isn't a hard problem—all you have to do is not totally fuck it up like sixel
i don't know, i'm not waiting around, i'm gonna be over here hacking on godot instead
> emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video
xterm supports sixel graphics.
"sixel" is an image file format; the ImageMagic "convert" command can convert other formats to it. Just cat a sixel file to stdout in an xterm and it's displayed in the window.
The implementation is not 100% solid (for example, there's a size limit), but it does work. And tmux can be build with sixel support, so you can display sixel images in tmux under xterm.
iterm's protocol can display gifs, could use a streaming method via that, Kitty's protocol supports manual animating, though I have a feel it wouldn't be able to do video.
mpv supports both sixel and kitty's method for doing video
Based on my (limited) understanding of Kitty's image protocol[0] (a.k.a the "Terminal graphics protocol") video support could be potentially implemented via multiple approaches, including at least:
(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].
(2) Draw image replacing an existing image with the same id.
(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").
An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:
* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.
* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.
* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].
---- footnotes ----
(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)
[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].
[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D
[4a] Motivated by the thought that at the current point in time perhaps the "essence" of a "terminal" is its linear "chronological" presentation of input/interaction/output history rather than its use of "text". (See also: "lab notebooks" & some tiling window manager features.)
> The vast majority of terminals will send the same sequences.
Not for function keys in particular not for the modifiers. Just take a look at the output of 'infocmp' between your favorite terminal and your favorite terminal with tmux running in it or even just a different terminal itself.
Another issue is knowing capabilities, total number of colors, allowed attributes, default state of attributes, allowed actions when certain attributes are enabled or disabled.
There's about half of the definitions which are common across almost all modern terminals, and the other half are unique and describe unique implementation details of the emulator.
There are several terminal codes that perform actions on the client, if the terminal impliments them.
Even just the code that changes the window title could even possibly be a security risk.
But the mother of all, in commercial terminals it's even a critical feature to have an escape code that literally executes an arbitrary string sent from the host to be executed on the client. Usually just to launch a browser or local document viewer, but could be anything.
I used it to scan and upload documents from a scanner attached to the users pc back to the host for instance. In years past it would be used to launch excel etc before pretty much everything became doable over the net in a browser.
To not pick on iTerm2, the problem isn't iTerm2 in general (except for some of it), but the "standards" per say sorta assume trusted terminals, which made sense for VTNNN, but not so much since the internet started existing.
There is kmscon, but yeah - it seems to be stalled and abandoned. I tried it and it sort of works, but feels buggy in some ways, so it needs work. That seems to have most promising potential if anyone could actually develop it.
BTW, with regard to specifying "true" RGB colour related escape codes, note that there's currently a couple of... "issues" with the content in this section: https://www.arp242.net/safeterm.html#true-colours
1. The format of the escape codes given for "True color" is "incorrect"[0], as it "should"[1] use `:` as the separator between the individual red, green & blue values supplied.
2. There is a minor typo/copypesto in "Foreground", where "R" is incorrectly listed twice and "G" is missing.
--- footnotes ---
[0] By "incorrect", I mean "not spec compliant", however, given the author expresses a sentiment of/preference for "I don’t care what some spec says; I care about what works" this presumably motivates their inclusion of the "non spec compliant" form in preference to the strictly spec compliant form[2]. :)
[1] The TLDR being that the entire colour specified by the "RGB" values is a "parameter" (and thus should be separated/surrounded by ";") but the individual "R", "G", "B" values are "parameter sub-strings" (a.k.a. "sub-parameters") and thus "need" to use a different separator: ":", the parameter sub-string separator.
However, for reasons[3], historically ";" was initially incorrectly used by some terminal emulators ("xterm", in particular) as both the parameter separator and the parameter sub-string separator. This error was apparently eventually discovered & corrected in xterm but the correction was not necessarily implemented/propagated to other existing/new terminal emulator implementations--or other tools that parse or generate the colour-related escape codes[4].
[2] This sentiment/preference is not shared by everyone, however, for example, the developer of WezTerm notes in its escape code reference documentation: "The colon form is unambiguous and should be preferred; the semicolon form should not be used by new applications and is not documented here in the interest of avoiding accidental new implementations"[8]. :)
[3] Money, or rather, lack thereof. The reason for the original error has been explained as "We [incorrectly] used semicolon [...] for separating the R/G/B values in the escape sequence, since a copy of [the related standard/specification] which presumably clarified the use of colon for this feature was costly."[5][6]
[4] The distinction between use of ";" vs ":" is also not only of "academic"/historic relevance--within the past month (while developing a customization[9] for WezTerm) I ran into an issue caused by spec-compliant vs non-spec-compliant implementations[7] between WezTerm (which generated spec-compliant colour escape codes) and at least some version(s) of `journalctl` which failed to parse & display a log message formatted with the spec-compliant colour and instead displays `[89B blob data]` (by default). This necessitated "munging" the correct escape codes into an incorrect abomination[10] in order for the log message to be formatted & displayed as intended by `journalctl`.
[6] For the "Too Long; Did Write:" version of the explanation see the two comments I wrote a year ago when I last fell into this particular rabbit hole, :D here: https://news.ycombinator.com/item?id=35157058 (When the digging leads to learning about the connections to co...
- ANSI escape sequences are a standard, and have been around since, what, 1976? Almost fifty years.
- POSIX doesn't specify terminfo.
- POSIX describes a tput utility command which supports only three operands: clear, init and reset, and mentions the TERM variable without giving concrete requirements about it.
Clearly, the standard-conforming, richly functional solution is to use the ECMA/ANSI control sequences!
terminfo is nonstandard, vendor-specific, legacy Unix cruft, standardizing which POSIX was not up to the task.
Any purely software based terminal emulator you're likely to come across will speak ANSI. Where you have the support problem is with legacy terminal hardware.
What is worse:
- our program that uses ANSI escapes not working with someone's nonstandard hardware terminal, but otherwise being highly portable; or
- our program requiring termios not working with any terminal, when ported to a certain platform, due to lack of termios on that platform.
For all practical matters it is xterm that has become the standard.
Like with web browsers, it is irrelevant what the standard states. The only thing that matters is that it displays correctly with the most popular / authoritative browser.
With browsers, it used to be irrelevant what the standard stated. But the standards these days are actually useful, and where implementations differ from the standards, one or the other is changed.
There are several different xterms. As in, really different with totally different Fkeys and arrows and colors etc, even while still being largely vt-like, but they all call themself the same TERM=xterm by default.
Based on my understanding of the situation this claim seems to perhaps be... a little lacking in nuance? :)
In a different context perhaps we'd be talking about "genericization of trademarks" but, at least as a term *cough* referring to a specific software application, well, "the" "xterm" docs[0] think there is "only" "one":
* "xterm (pronounced 'eks-term') is a specific program, not a generic item. It is the standard X terminal emulator program."
Then again, even with a narrow definition of "the standard X terminal emulator program", the xterm moniker can apparently apply to two "implementations"[1], variously[1][2] referred to as "xterm-new" (a.k.a "based on XFree86 xterm" a.k.a. "modern" a.k.a "based on the X11R6.3 xterm, with the addition of ANSI color and VT220 controls") and "xterm-old" (a.k.a "the X11R6 xterm" a.k.a. "xterm-r6").
And, indeed, the docs do use the phrase "other versions of xterm"[3] in reference to:
* other programs "based on xterm's source"
However, it also distinguishes between those programs and programs in two further categories:
* "similar programs not based on xterm's source, which are compatible to different degrees"
* "programs which set TERM to 'xterm', in the hope that applications will treat them the same as xterm" (which apparently includes some whose developers think that by "[...] copying from xterm [source code], they are entitled to do this whether or not the program actually matches xterm's terminal description").
Which segues nicely into...
> they all call themself the same TERM=xterm by default
A habit that the main developer of xterm since 1996 appears to have, um, some additional thoughts about: :D
Hey, maybe we should replace `TERM=` with `USER_AGENT="$TERM (Compatible with xterm)"`, cos that worked out great on the web! :)
Now, some people may respond "No, we should be using feature detection!", to which I might respond, "Hey, yeah, like, we should have a way to find out what features or capabilities the current terminal emulator supports!".
Problem solved!
Guess the only question now is whether we should call it "The Terminal Capabilities System" or "The Terminal Information System"...
...wait, no, those names don't sound... "unixy" enough.
Let's call it "terminfo". Yeah, let's use "terminfo"!
To which I imagine, at least one person might reply, with a sigh, "I wish you would":
Wait, so, why doesn't this system "work" then? Well, turns out, apparently its "easier" to just tell someone to set `TERM` to a value which might charitably be called "aspirational" an...
xterm, the term used in error to refer to the definition of a particular terminal, is used by several different implimentations going back decades and spanning many platforms.
Those implimentations not only all assert the exact same "TERM=xterm" by default, many of them even name the executable the same "xterm", yet do not all adhere to any single common standard. The SCO OSR5 xterm is different from old versions of Xfree86 xterm is differrent from the current xorg xterm etc. There is some overlap, but not nearly enough. The differences are not merely small superset/subset feature differences like 256 color support etc. They include, as I did say, totally differrent F-keys and arrows for example.
That is what "xterm is not a standard" means.
It's a word that refers to a range of different definitions that depend on context, not a single specific definition that always means the same thing in any context, and so is not a meaningful definition, or standard.
32 comments
[ 3.4 ms ] story [ 83.8 ms ] threadI disagree. The vast majority of terminals will send the same sequences. There is almost never a case where handling the two options for backspace the same way will result in a bad user experience. What complicates this even more is that many terminals allow the user to modify which sequence the `Backspace` key sends (0x08 vs 0x7F). Any application relying on terminfo, where a user did not modify their terminfo entry, will interpret these wrong if a user has manually changed it.
Terminfo is not needed anymore. It served a purpose to let applications know how to talk to a terminal. That era is gone.
> Key input handling is kind of a mess, and this is where I really recommend using a terminfo library if at all possible. This also avoids the whole backspace/delete key confusion (less of an issue today than it used to be, but still exists).
Of course lots of applications don't use backspace or delete; sometimes you just want the ability to select between 3 items with j/k and arrow keys, or something like that. And if this is something just for yourself or a limited audience then it's fine to just read that from stdin and not worry too much.
if someone found it unconvincing the first time, or found rockorager's rebuttal to it convincing, hopefully a mere repetition of your comment will not change that. and, if they found it convincing the first time and found rockorager's rebuttal unconvincing, repeating it is unnecessary
All of that said, I am a huge proponent of the kitty keyboard protocol. I would love to live in a world where the "default" encoding of keys is done with the that protocol (with the disambiguate flag on)
Right, I read that the other way round ("no, you do need terminfo for key input")!
For basic input it's fairly straight-forward, and even for various "special" keys like arrows and function keys it's not too bad: just check from a list.
But with modifier keys it gets more tricky; lots of that isn't even in terminfo and requires "special" handling.
If you know how this works and you know what you're doing it can be fine, but for most people it's far easier to just use a terminfo library that does this for you.
And yeah, Kitty keyboard protocol being the default would be brilliant. Right now support is (far) too flaky though, so maybe in 5 to 10 years.
So I don't know how needed it is anymore. But I will have a hard time giving up terminfo and going over to the darkside.
Most terminals today are mostly vt-like? So the F what?
Whether anyone likes it or not, or beleives it or not because of their own limited direct personal experience, the problem that termcap/terminfo worked around still exists today.
Since the problem still exists, the solution (or I would call it more of a work-around) is still required. Simply pretending or ignoring doesn't resolve anything.
When some spec becomes a decreed standard that you can actually count on, like we take one of the many vt-alikes and enshrine that one and all terminals are actually required to impliment that spec exactly, then you can maybe talk about "we don't need termcap or terminfo any more, it's ok to hard-code this spec from now on"
And I won't even start on all the things wrong with "just map both to up arrow" holy cow.
Could you humour us with just a couple of the things wrong with it? Cos I'm certainly interested to learn more about it. :)
three options for this inner terminal emulator are gnu screen (previously iscreen, which was a better name), tmux, and emacs term-mode. all three of these can use terminfo to figure out how to manipulate the outer terminal—but they wouldn't have to. mosh also does this terminal-emulator-inception thing but i think it's hardcoded to use ansi escape sequences to draw
— ⁂ —
what i'd really like to see is a reimagining of the terminal interface as something better than a vt340+. we have lots of historical things that could be sort of described that way (genera's lisp listener, the blit, mgr, caleb winston's stdg, notty, x11, postscript, html, react, wayland, opengl, vulkan, vnc) but they all fall short in one way or another. minimally i want a user interface that i can
1. write programs for in any programming language such that
2. simple programs like 'hello, world' or displaying a two-column table of numbers are about as simple as in an xterm, and
3. the programs' input and output is manipulable by the user at various levels of abstraction (copy/paste, screenshots, editing the output text, automating interactive workflows (like expect/autohotkey/selenium), screen readers, asciinema/screencasting, livestreaming, obs studio), and
4. the program is interactive (html kind of fails at this), and
5. the user interface can be used on a separate computer from the program (maybe the user interface runs on a cellphone while the program runs on a rack in a data center, or maybe the user interface runs on a laptop while the program runs on a quadcopter), and
6. small computers (under a megabyte of ram) can be used to show the program's user interface, but
7. the program can display anything the user's monitor is physically capable of displaying and support any of the user's input devices, including mice, touchscreens, accelerometers, cameras, etc.
emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video
obviously there's some degree of tradeoff in some cases between 5, 6, and 7, because you aren't going to stream 4k video over a 9600-baud serial line, and you aren't going to decode it on a 286 (nor are you going to stream webcam video back from the user if the webcam is plugged into a 286), but there's a pretty broad spectrum today of {comms bandwidth, terminal cpu, desired output} triples for which performance isn't a hard problem—all you have to do is not totally fuck it up like sixel
i don't know, i'm not waiting around, i'm gonna be over here hacking on godot instead
xterm supports sixel graphics.
"sixel" is an image file format; the ImageMagic "convert" command can convert other formats to it. Just cat a sixel file to stdout in an xterm and it's displayed in the window.
The implementation is not 100% solid (for example, there's a size limit), but it does work. And tmux can be build with sixel support, so you can display sixel images in tmux under xterm.
or https://en.wikipedia.org/wiki/SixelNo, there's no video support (unless I've missed something).
mpv supports both sixel and kitty's method for doing video
(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].
(2) Draw image replacing an existing image with the same id.
(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").
An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:
* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.
* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.
* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].
---- footnotes ----
(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)
[0] https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-...
[1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...
[1b] This approach appears to be the method used by the mpv implementation: https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56...
[2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...
[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].
[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D
[4a] Motivated by the thought that at the current point in time perhaps the "essence" of a "terminal" is its linear "chronological" presentation of input/interaction/output history rather than its use of "text". (See also: "lab notebooks" & some tiling window manager features.)
[5] https://github.com/michaeljclark/glkitty
[6] https://github.com/chase/awrit
[7] Which I imagine DEC is turning in its grave about. :)
it's unfortunate that it's still only six bits per byte, but at least it supports png and 24-bit color
Not for function keys in particular not for the modifiers. Just take a look at the output of 'infocmp' between your favorite terminal and your favorite terminal with tmux running in it or even just a different terminal itself.
Another issue is knowing capabilities, total number of colors, allowed attributes, default state of attributes, allowed actions when certain attributes are enabled or disabled.
There's about half of the definitions which are common across almost all modern terminals, and the other half are unique and describe unique implementation details of the emulator.
(The author’s title is fine — just uses a different meaning of “safe”)
I suspect that in a sufficiently fast terminal emulator you could get up to some shenanigans with some judiciously chosen terminal controls.
Even just the code that changes the window title could even possibly be a security risk.
But the mother of all, in commercial terminals it's even a critical feature to have an escape code that literally executes an arbitrary string sent from the host to be executed on the client. Usually just to launch a browser or local document viewer, but could be anything.
I used it to scan and upload documents from a scanner attached to the users pc back to the host for instance. In years past it would be used to launch excel etc before pretty much everything became doable over the net in a browser.
To not pick on iTerm2, the problem isn't iTerm2 in general (except for some of it), but the "standards" per say sorta assume trusted terminals, which made sense for VTNNN, but not so much since the internet started existing.
It would be nice for Linux built-in framebuffer tty to support true color. I wonder why it doesn't yet.
The last mentioned comment seems to be "it needs a large amount of code". So it should be possible in general?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
1. The format of the escape codes given for "True color" is "incorrect"[0], as it "should"[1] use `:` as the separator between the individual red, green & blue values supplied.
2. There is a minor typo/copypesto in "Foreground", where "R" is incorrectly listed twice and "G" is missing.
--- footnotes ---
[0] By "incorrect", I mean "not spec compliant", however, given the author expresses a sentiment of/preference for "I don’t care what some spec says; I care about what works" this presumably motivates their inclusion of the "non spec compliant" form in preference to the strictly spec compliant form[2]. :)
[1] The TLDR being that the entire colour specified by the "RGB" values is a "parameter" (and thus should be separated/surrounded by ";") but the individual "R", "G", "B" values are "parameter sub-strings" (a.k.a. "sub-parameters") and thus "need" to use a different separator: ":", the parameter sub-string separator.
However, for reasons[3], historically ";" was initially incorrectly used by some terminal emulators ("xterm", in particular) as both the parameter separator and the parameter sub-string separator. This error was apparently eventually discovered & corrected in xterm but the correction was not necessarily implemented/propagated to other existing/new terminal emulator implementations--or other tools that parse or generate the colour-related escape codes[4].
[2] This sentiment/preference is not shared by everyone, however, for example, the developer of WezTerm notes in its escape code reference documentation: "The colon form is unambiguous and should be preferred; the semicolon form should not be used by new applications and is not documented here in the interest of avoiding accidental new implementations"[8]. :)
[3] Money, or rather, lack thereof. The reason for the original error has been explained as "We [incorrectly] used semicolon [...] for separating the R/G/B values in the escape sequence, since a copy of [the related standard/specification] which presumably clarified the use of colon for this feature was costly."[5][6]
[4] The distinction between use of ";" vs ":" is also not only of "academic"/historic relevance--within the past month (while developing a customization[9] for WezTerm) I ran into an issue caused by spec-compliant vs non-spec-compliant implementations[7] between WezTerm (which generated spec-compliant colour escape codes) and at least some version(s) of `journalctl` which failed to parse & display a log message formatted with the spec-compliant colour and instead displays `[89B blob data]` (by default). This necessitated "munging" the correct escape codes into an incorrect abomination[10] in order for the log message to be formatted & displayed as intended by `journalctl`.
[5] See: https://invisible-island.net/xterm/xterm.faq.html#color_by_n...
[6] For the "Too Long; Did Write:" version of the explanation see the two comments I wrote a year ago when I last fell into this particular rabbit hole, :D here: https://news.ycombinator.com/item?id=35157058 (When the digging leads to learning about the connections to co...
Here is one way to answer the question.
- ANSI escape sequences are a standard, and have been around since, what, 1976? Almost fifty years.
- POSIX doesn't specify terminfo.
- POSIX describes a tput utility command which supports only three operands: clear, init and reset, and mentions the TERM variable without giving concrete requirements about it.
Clearly, the standard-conforming, richly functional solution is to use the ECMA/ANSI control sequences!
terminfo is nonstandard, vendor-specific, legacy Unix cruft, standardizing which POSIX was not up to the task.
Any purely software based terminal emulator you're likely to come across will speak ANSI. Where you have the support problem is with legacy terminal hardware.
What is worse:
- our program that uses ANSI escapes not working with someone's nonstandard hardware terminal, but otherwise being highly portable; or
- our program requiring termios not working with any terminal, when ported to a certain platform, due to lack of termios on that platform.
Like with web browsers, it is irrelevant what the standard states. The only thing that matters is that it displays correctly with the most popular / authoritative browser.
xterm is not a standard.
Based on my understanding of the situation this claim seems to perhaps be... a little lacking in nuance? :)
In a different context perhaps we'd be talking about "genericization of trademarks" but, at least as a term *cough* referring to a specific software application, well, "the" "xterm" docs[0] think there is "only" "one":
* "xterm (pronounced 'eks-term') is a specific program, not a generic item. It is the standard X terminal emulator program."
Then again, even with a narrow definition of "the standard X terminal emulator program", the xterm moniker can apparently apply to two "implementations"[1], variously[1][2] referred to as "xterm-new" (a.k.a "based on XFree86 xterm" a.k.a. "modern" a.k.a "based on the X11R6.3 xterm, with the addition of ANSI color and VT220 controls") and "xterm-old" (a.k.a "the X11R6 xterm" a.k.a. "xterm-r6").
And, indeed, the docs do use the phrase "other versions of xterm"[3] in reference to:
* other programs "based on xterm's source"
However, it also distinguishes between those programs and programs in two further categories:
* "similar programs not based on xterm's source, which are compatible to different degrees"
* "programs which set TERM to 'xterm', in the hope that applications will treat them the same as xterm" (which apparently includes some whose developers think that by "[...] copying from xterm [source code], they are entitled to do this whether or not the program actually matches xterm's terminal description").
Which segues nicely into...
> they all call themself the same TERM=xterm by default
A habit that the main developer of xterm since 1996 appears to have, um, some additional thoughts about: :D
* https://invisible-island.net/ncurses/ncurses.faq.html#xterm_...
* https://invisible-island.net/xterm/xterm.faq.html#xterm_term...
Hey, maybe we should replace `TERM=` with `USER_AGENT="$TERM (Compatible with xterm)"`, cos that worked out great on the web! :)
Now, some people may respond "No, we should be using feature detection!", to which I might respond, "Hey, yeah, like, we should have a way to find out what features or capabilities the current terminal emulator supports!".
Problem solved!
Guess the only question now is whether we should call it "The Terminal Capabilities System" or "The Terminal Information System"...
...wait, no, those names don't sound... "unixy" enough.
Let's call it "terminfo". Yeah, let's use "terminfo"!
To which I imagine, at least one person might reply, with a sigh, "I wish you would":
* https://invisible-island.net/xterm/terminfo-contents.html#ti...
* https://invisible-island.net/xterm/terminfo-contents.html#ti...
* https://invisible-island.net/xterm/terminfo-contents.html#ti...
* etc
Wait, so, why doesn't this system "work" then? Well, turns out, apparently its "easier" to just tell someone to set `TERM` to a value which might charitably be called "aspirational" an...
Those implimentations not only all assert the exact same "TERM=xterm" by default, many of them even name the executable the same "xterm", yet do not all adhere to any single common standard. The SCO OSR5 xterm is different from old versions of Xfree86 xterm is differrent from the current xorg xterm etc. There is some overlap, but not nearly enough. The differences are not merely small superset/subset feature differences like 256 color support etc. They include, as I did say, totally differrent F-keys and arrows for example.
That is what "xterm is not a standard" means.
It's a word that refers to a range of different definitions that depend on context, not a single specific definition that always means the same thing in any context, and so is not a meaningful definition, or standard.