Date: Thu, 7 May 2020 11:00:56 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Baptiste Daroussin <bapt@freebsd.org>, FreeBSD Current <current@freebsd.org> Subject: Re: Move from termcap(5) to terminfo(5) Message-ID: <CANCZdfpRTt8x%2BOF5_=s0GnbsTXXCZGB_dtCNOvGQhfMt3XsOxg@mail.gmail.com> In-Reply-To: <202005071635.047GZGC3048718@gndrsh.dnsmgr.net> References: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> <202005071635.047GZGC3048718@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 7, 2020 at 10:35 AM Rodney W. Grimes < freebsd-rwg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpRTt8x%2BOF5_=s0GnbsTXXCZGB_dtCNOvGQhfMt3XsOxg>