![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Over the last year or so, I've spent quite a number of hours fighting with the terminfo system to get certain tools I use on assorted systems I log in to to be able to send information to the status line (usually the title bar in xterm and most other terminal emulators). This has been a struggle primarily because certain RedHat derivatives ship with a terminfo database containing a broken information file for screen (lacking definitions for tsl and fsl). I finally learned that you can augment the terminfo database with local settings in your homedir (this they got right). At this point I feel I've learned quite a bit about terminfo and its predecessor, TERMCAP, and I have a simple question:
Why the hell did we go from TERMCAP to terminfo?
terminfo stores a static database of all the capabilities of every terminal which might ever be encountered. If you use a new terminal (that is, one with an unknown name), the database must be augmented with its capabilities. Why the inflexibility? Now that I'm trying out a relatively obscure terminal emulator (rxvt-unicode), and typically run it under screen, I pretty much have to create ~/.terminfo/r/rxvt-unicode and ~/.terminfo/s/screen.rxvt-unicode on every system I connect to. And if I connect to a system which doesn't give me a homedir for some reason, I'm pretty much screwed (or have to remember to lie about what TERM I'm using before I connect).
Compare with TERMCAP. The terminal informs the login shell of its capabilities through an environment variable. This means that if it's configured with different capabilities than the stock (say I've enabled/disabled colors differently from the expectation), it can inform the system. And if it's a brand-new terminal, the system doesn't have to have heard of it. I wouldn't have to go to drop files on every system I connect to letting them know about my terminal.
Yeah, there are severe problems with the TERMCAP approach (environment variables are often limited in length), but when they reinvented the wheel to overcome the limitations, what the hell were they thinking in taking away the most useful feature, the ability for the terminal to inform anything which cares about its capabilities, rather than the system having to know about every possible terminal?
Seriously, does anybody have any insight on this?
no subject
Hmm. A good way to do it in the modern, network architecture, would be to have terminals use a URI to describe their capabilities. That way, term info can be distributed through the network (but still cached so it's only network dependant when you connect a new terminal to a machine for the first time in a while/ever).
no subject
You're doing the same thing terminfo is, though, and having a static capability description for each terminal type. But they're not actually static. For instance, I can configure the number of colors rxvt-unicode should use to one of a number of settings, and the system I'm logged into needs to know what this instance is capable of. If there are more than a couple of settings like this which affect the capabilities, that's going to get huge fast.
no subject
What if you have, not a URI, but a list of URIs, which capability queries sequence against? So if you had, say:
TERMURI=http://site.com/termuri/colornum?32:http://site.com/termuri/vector:http://site.com/termuri/xterm
then you'd know that the current terminal is an xterm, but has the "vector" capability (whatever that is), and also has 4 colors rather than what was specified in the xterm URI--the list of URIs would be treated as a union of all of them, except that earlier records would overrride (and mask out) later, conflicting records.
Of course, you could do the same by having the URI source accept parameters and produce a dynamic description -- as I demonstrate in the first uri example. But that might require too much intelligence in the URI hosts, perhaps, and frustrate caching.