Terminfo was never a particularly good idea, but in today's day and age it has become simply ridiculous. Its original purpose was to store data about actually manufactured physical terminals, and so it was okay that it was a fixed DB (as opposed to interactively querying the terminal for its capabilities somehow).
These days though, terminals are all software. It would be very easy to just ask them. Instead we still insist on shipping a fixed terminfo or termcaps DB. As a consequence, every new terminal emulator is not in there, and so in order to give their users a tolerable experience, they all lie and say they're xterm-256color. Which completely removes any incentive to actually add them to terminfo/termcaps.
So we have this hellishly complex, nearly Turing complete compatibility system that does no useful work at all anymore.
> It would be very easy to just ask them. Instead we still insist on shipping a fixed terminfo or termcaps DB.
Isn’t the terminal info easily modifyable? You can add new entries at both the system and user level.
The only actual issues are capabilities. But just like all protocols, there’s need to be an agreement between the software and the terminal. And gradual degradation if some capability is not there. I have more issue with some software hardcoding escape sequences than with not being able to add new terminal entries.
Yes you can add entries, but it's still an awful design. It's like if the web didn't have media queries and such and instead everyone ships a big database of user agent strings that websites check in order to know what features they can use.
And no, caniuse or browserlist are not that. Yes they contain data on what browsers support what, but that's only to guide your compatibility decisions. You can still opportunistically try to use a feature and a new browser that's not in the DB can handle it correctly without having to lie in its UA string.
> It's like if the web didn't have media queries and such and instead everyone ships a big database of user agent strings that websites check in order to know what features they can use.
Do remember that both the interface (the terminal) and the software environment is under the control of the same user. And terminfo is more of a translation layer than a database, more like the Linux virtual filesystem which hides away the different filesystem implementations. Or ALSA and DRM.
Going back to the issue on the software side, many time, the only check they do is checking if stdout is a file or a tty. If it’s the latter, their output is full of color and spinners, no matter if TERM is explicitly ’dumb’.
> as opposed to interactively querying the terminal for its capabilities somehow
Querying terminals, in the 1970s when there was a Cambrian explosion in terminal capabilities, with tens of different manufacturers?
Even if you could have gotten all of them to agree this was necessary, I think nobody could afford to put the smartness for such a protocol in their hardware. Hardware was expensive in those days.
I remember finding the original terminfo Turing completeness article, which was published in 2019, amazing.
In the era of LLMs articles such as these do nothing for me any more.
This article is mostly, if not entirely, LLM-generated. It’s done in a slightly less blatant way than most, but the tells are there, and pangram agrees.
But even if the article was human-written, I’d still not find it impressive now. There’s no way of telling a human was behind the discovery.
There is a system that I’ve dealt with for a long time, and wondered if it was Turing complete. After many years of thinking “I’ll prove it one day”, I broke down and asked Sol. Five minutes later, I had a proof.
Terminfo was never a particularly good idea, but in today's day and age it has become simply ridiculous. Its original purpose was to store data about actually manufactured physical terminals, and so it was okay that it was a fixed DB (as opposed to interactively querying the terminal for its capabilities somehow).
These days though, terminals are all software. It would be very easy to just ask them. Instead we still insist on shipping a fixed terminfo or termcaps DB. As a consequence, every new terminal emulator is not in there, and so in order to give their users a tolerable experience, they all lie and say they're xterm-256color. Which completely removes any incentive to actually add them to terminfo/termcaps.
So we have this hellishly complex, nearly Turing complete compatibility system that does no useful work at all anymore.
> It would be very easy to just ask them. Instead we still insist on shipping a fixed terminfo or termcaps DB.
Isn’t the terminal info easily modifyable? You can add new entries at both the system and user level.
The only actual issues are capabilities. But just like all protocols, there’s need to be an agreement between the software and the terminal. And gradual degradation if some capability is not there. I have more issue with some software hardcoding escape sequences than with not being able to add new terminal entries.
Yes you can add entries, but it's still an awful design. It's like if the web didn't have media queries and such and instead everyone ships a big database of user agent strings that websites check in order to know what features they can use.
And no, caniuse or browserlist are not that. Yes they contain data on what browsers support what, but that's only to guide your compatibility decisions. You can still opportunistically try to use a feature and a new browser that's not in the DB can handle it correctly without having to lie in its UA string.
> It's like if the web didn't have media queries and such and instead everyone ships a big database of user agent strings that websites check in order to know what features they can use.
Do remember that both the interface (the terminal) and the software environment is under the control of the same user. And terminfo is more of a translation layer than a database, more like the Linux virtual filesystem which hides away the different filesystem implementations. Or ALSA and DRM.
Going back to the issue on the software side, many time, the only check they do is checking if stdout is a file or a tty. If it’s the latter, their output is full of color and spinners, no matter if TERM is explicitly ’dumb’.
> as opposed to interactively querying the terminal for its capabilities somehow
Querying terminals, in the 1970s when there was a Cambrian explosion in terminal capabilities, with tens of different manufacturers?
Even if you could have gotten all of them to agree this was necessary, I think nobody could afford to put the smartness for such a protocol in their hardware. Hardware was expensive in those days.
You read the opposite of what that post is saying. It says a fixed DB was okay in the 1970s, but not in the 2020s.
I remember finding the original terminfo Turing completeness article, which was published in 2019, amazing.
In the era of LLMs articles such as these do nothing for me any more.
This article is mostly, if not entirely, LLM-generated. It’s done in a slightly less blatant way than most, but the tells are there, and pangram agrees.
But even if the article was human-written, I’d still not find it impressive now. There’s no way of telling a human was behind the discovery.
There is a system that I’ve dealt with for a long time, and wondered if it was Turing complete. After many years of thinking “I’ll prove it one day”, I broke down and asked Sol. Five minutes later, I had a proof.
This article? https://weinholt.se/articles/terminfo-and-its-dsl/
Does it play Doom yet??