terminfo

[Bruce Evans]

On Fri, 21 Feb 2014, Peter Wemm wrote:

> On Wed, Feb 19, 2014 at 4:17 AM, 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. 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?
>
> There are historical reasons.  As the person who imported the current
> setup I have some insight into that.
>
> One issue was because cons25 / syscons was evolving.  That's no longer
> the case.  Because things were in flux, people accumulated their own
> rules.  Another was that termcap was the source of truth on 4.x BSD
> systems, but we could translate into terminfo dynamically for things
> that needed it.  At the time, the reverse wasn't adequate - the
> ncurses provided terminfo wasn't rich enough to express everything we
> had in termcap so we couldn't do a lossless conversion of our home
> grown termcap rules into terminfo and get everything back through the
> emulator.  There were personal preferences as well - the ncurses
> terminfo at the time was sysv-style and was a fixed binary format and
> non-extensible while termcap was flexible and freely extendable.

My preference is to have not stopped using 4.4BSD termcap and curses,
except to simplify it a bit.  NetBSD was still using 4.4-based
libterm and libcurses in 2005, except to expand them a lot.

> HOWEVER, if I were to do it today, I would be inclined to use netbsd's
> libtinfo and cdb modules and switch to terminfo as the source of
> truth.  It is my understanding that netbsd's libtinfo "compiles" into
> a .cdb format file and gives us the same flexibility that we have with
> termcap/termcap.db without the non-extensible sysv binary format
> lock-in.  Then have ncurses use it instead, like netbsd does.  We get
> to import the ncurses sourced terminfo database and port over our
> tweaks/extensions as needed.

Ugh, more binary mistakes.  This reminds me that I wanted to remove the
.db form in ~1995.  Even in 1995, you could read and parse the whole 200K
termcap.src file in not very long compared with the startup time of
an interactive application large enough to use termcap.  But it is even
better to not have a big termcap file full of support for hardware
terminals that haven't been produced since 1985.  This is most easily
implemented (incorrectly) by copying a few fixed entries to /etc/termcap
at install time.  I think users have always been able to get a faster
startup by copying the one entry that they use (or currently use) to
ther TERMCAP environment variable or their .termcap (hopefully the
implementation doesn't look elsewhere then).

Bruce