Subject: Re: A solution for termcap lossage?
To: None <tech-misc@netbsd.org,>
From: Greg A. Woods <woods@most.weird.com>
List: tech-userlevel
Date: 04/21/1999 13:09:00
[ On Wednesday, April 21, 1999 at 22:48:47 (+0930), Brett Lymn wrote: ]
> Subject: A solution for termcap lossage?
>
>         Unfortunately, tweaking termcap does not get us POSIX
> compliance.  For that we must have terminfo.  This does not please me
> but thems the breaks.  I certainly am opposed to the "maze of twisty
> little files, all the same" concept for terminfo that is implemented
> on all the SVRx machines I have ever seen.  I think we can do better
> than that.  My tentative thoughts on this are to have a single source
> for both terminfo and termcap and proffer the appropriate information
> depending on how the information is accessed - i.e. if tgetent is used
> then you get a termcap style if the terminfo calls are used you get
> terminfo style.

There has been a totally free (i.e. public domain) termlib/termcap
library that can read either terminfo files or termcap entries for quite
a few years now.  An adapted version of this code is included in
ncurses to convert entries from termcap to terminfo.

Personally I'd like to see NetBSD just switch to ncurses-4 and be done
with it.  Ncurses-1 is a dead-end and our current curses sucks big time
(and has also been declared a dead-end).  FYI:  "Beginning with release
4.2, ncurses is distributed under an MIT-style license."  If this is
already being done now behind the scenes, whomever is doing it should
let me know if there's anything I can do to help.

BTW, if you do any serious amount of localization of terminal support
terminfo files are a *LOT* easier to manage.  It's possible to do
reasonable termcap support using the original termcap database sources,
but this is not normally within the domain of the average system
administrator.  The fact that the terminfo 'database' is actually a
collection of many files, spread out amongst a set of directories in
order to eliminate performance problems, is totally irrelevant
(i.e. it's just an implementation detail) -- what's important is the way
an administrator can trivially update individual entries in the database
without editing and merging stuff into one big file where conflicts and
ordering are much more difficult issues to avoid.  Any storage scheme is
*possible* with terminfo -- it's just one heck of a lot simpler to
maintain binary compatability if you have to run third-party binaries
that might have been statically compiled with someone else's
implementation.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>