terminfo

[Warner Losh]

On Feb 21, 2014, at 8:46 AM, Ian Lepore wrote:

> On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote:
>> Hi Bryan,
>> 
>> On 19 February 2014 13:17, Bryan Drewery <bdrewery at freebsd.org> wrote:
>>> Why do we not use terminfo? Our termcap is quite aged and missing a lot
>>> of modern terminals/clients.
>> 
>> It is true that our termcap is quite aged, but the fact is, once you
>> add entries for a certain terminal, there's little need to update it
>> after that. ncurses itself is not really a moving target. What kind of
>> modern terminals/clients are missing?
>> 
>>> Using terminfo would allow us to use the already well maintained database from ncurses. Is it just a matter of someone doing the work or are there other reasons?
>> 
>> It's just a matter of someone doing the work. It would be nice if we
>> ever made this change.
>> 
>> On the other hand, I might have a radical point of view here: maybe we
>> could consider taking the approach of sticking to termcap and
>> installing /etc/termcap.small as the system's default termcap. Or
>> maybe patch up our termcap routines to just hardcode the sequences.
>> 
>> I won't deny that termcap was really useful at one point in time, but
>> let's be honest: the variety of terminals out there has massively
>> dropped over time. Terminal emulation has become a solved problem. As
>> of FreeBSD 9, syscons supports all the sequences described in
>> xterm-256color, though it isn't able to print more than 8 colours,
>> which is why we use TERM=xterm. Tools like screen, tmux, etc., they
>> use a different TERM type, but this is mainly used to detect whether
>> the process is running inside of screen or tmux. It does not strongly
>> affect the kinds of sequences that are being emitted. They work
>> perfectly fine if you just set TERM to xterm or xterm-256color.
>> 
>> I suspect the following logic would be sufficient for at least 99.5%
>> of our users:
>> 
>> if $TERM contains 256
>>  use xterm-256color
>> else
>>  use xterm
>> 
>> It's a shame I am so short on time nowadays, but I think it would make
>> so much sense to just come up with some kind of document that
>> standardizes the intersection of the features supported by most common
>> terminal emulators and get it rubber stamped by the maintainers of
>> various terminal emulators. If it turns out some kind of terminal
>> emulator does something in a non-standard way, we can just slap this
>> document in the author's face. That would not only benefit FreeBSD,
>> but also most of the other flavours of UNIX.
>> 
>> $TERM should die.
>> 
> 
> All of that seems to assume that every terminal actually being used in
> the world today is either xterm or something that emulates it.  Try
> using vi on a serial console on an embedded ARM board and you'll get a
> quick frustrating lesson in how not-xterm a serial console is.  I've yet
> to find a combo of serial comms program and TERM setting that actually
> works well and lets you edit a file with vi.

I'd go so far as to say that no such subset actually exists. There's nothing wrong with TERM, and it has abstracted away all the differences for many, many years.

I've had good luck with TERM=vt100 in those situations, but I use tip and apart from eating ^P it does a good job of being transparent enough...

Let's not kill $TERM... There seems to be no benefit, and lots of pain.

Warner