Re: Move from termcap(5) to terminfo(5)

On Thu, May 7, 2020 at 10:35 AM Rodney W. Grimes <
freebsd-rwg_at_gndrsh.dnsmgr.net> wrote:

> > Hello everyone,
> >
> > I can't find any proper rationale in our history (maybe I missed it)
> which
> > explains why our ncurses is stuck on using termcap(5) instead of
> terminfo(5)
> > Except an argument in the Makefile that builds ncurses:
> > "Used instead of the hideous read_termcap.c abomination."
> >
> > Which I do not find really useful.
> >
> > I would like to make the move from termcap to terminfo which would give
> us the
> > bonus to be able to track terminfo sources from upstream aka ncurses and
> to
> > add and use tic(1).
> >
> > Given the very few people that are actually maintaining the termcap
> database. I
> > don't think there is a good rationale at keeping our own format (as far
> as I
> > know everyone moved to terminfo(5)) and parser.
> >
> > Without any strong arguments against it I will start working on that
> move by
> > next week.
> >
> > If you have some knowledge you want to share: "be careful about this or
> that" I
> > would be more than happy to collect it, to make sure the transition is
> as smooth
> > as possible.
>
> The feedback I have from the few people that *are* effected by our
> lack of use of terminfo is positive on this change.
> Our use of termcap is a pain for them, especially with the base vs
> ports issues.
>

There are a number of people, though, that have custom TERMCAP entries in
their environment, or that do special things with /etc/termcap that will
need to be consulted. The TERMCAP env variable is likely the hardest to
convert, though they work around various bugs that have been in various
flavors of ncurses over the years. The impact here is likely small, but
likely non-zero as some of the bugs are worked around in other ways these
days (eg screen save/restore: bug or feature).

nanobsd used to deploy a tiny termcap file for space reasons. There's a
number of other custom image building scripts in the community that I'm
aware of that do this too, though I don't think any are publicly available.
The reworking isn't super hard for nanobsd, so long as tic produced target
independent binaries. There may be some work needed in nanobsd if the tic
files are big in aggregate to trim them down to vt100/xterm/cons25.


> As far as I am aware the termcap vs terminfo is simply historical in
> nature with no strong reason to change it.  It use to be that both
> had pretty close shares of the supported by software segment.  That
> historical precedence has worn thin, as there is very little support
> for termcap today.
>

terminfo was AT&T System V and very jealously guarded at the start of the
project. Given the other issues the project had in the early days with USL,
poking the bear by switching to terminfo, even one that was clean room
done, was simply not an option. It was BSD and there has been zero pressure
to change until this thread (though I see others have brushed up against
this issue before now)...

As with other deprecations of user facing interfaces, announcing the
timeline, etc should be done here. It's not a huge deal, assuming tic
produces sensible binaries that are platform neutral. If it doesn't, then
the transition will be harder...

Warner