Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Jan 2002 00:11:57 -0600
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG
Subject:   Re: termcap versus terminfo
Message-ID:  <20020117061157.GA84018@dan.emsphone.com>
In-Reply-To: <3C462D9C.D81306FD@mindspring.com>
References:  <20020116165926.N451@canonware.com> <3C462D9C.D81306FD@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jan 16), Terry Lambert said:
> Jason Evans wrote:
> > I would like to move FreeBSD to a much less hacked ncurses, which
> > means converting to terminfo.  Are there any good reasons for not
> > making this change?
[...]
> > 5) terminfo is generally better designed.  termcap has scalability
> >    issues, which we have partially solved by creating termcap.db. 
> >    However, the speedups afforded by the db file only help if using
> >    the termcap library API, since termcap.db does not have a public
> >    API to allow direct access. By contrast, the terminfo database
> >    is in a compiled format that is formally documented, which
> >    allows applications to quickly access terminfo entries without
> >    using the terminfo library API.

Isn't using an API better than codifying a file format?  And how is an
application even going to know where the system put its terminfo files
when it decides to bypass the API?  And the .05 second saved by having
the terminal description precompiled will be in the noise when we stop
caching catpages.

Another drawback with terminfo is there's no provision for
non-disk-based terminal descriptions.  With termcap, a program
simulating its own termcal (screen, or emacs for example) can simply
set TERMCAP to the terminal description itself and not worry about
whether the system's termcap/terminfo is right.  Same thing for telnet
and ssh.  They both have the ability to pass TERMCAP to a remote
system.  Handy when connecting to OSes that don't have a description
for cons25.

[...]
> I think the place to move the hack boundary is still inside the
> ncurses code.  This is a problem with the ncurses code (IMO), not a
> problem with BSD.

How much hacking is really involved?  Every terminfo-using OS here at
work (Linux, tru64, Solaris, SCO) has a different on-disk terminfo
structure (surprise surprise), so the first thing I do is install
ncurses with the following to generate a nice /etc/termcap-friendly
lib:

./configure --prefix=/usr/local/ --enable-termcap --enable-getcap --disable-overwrite

I would assume that whatever things get set by these --flags are simply
#defines in a config.h file.  Are there any other changes that are
needed to get a true termcap-only ncurses?  

If you're worried about the maintaining the source terminal description
file, you can always keep "terminfo.src" in CVS and run infotocap on it
during the build to generate a terminfo file.

-- 
	Dan Nelson
	dnelson@allantgroup.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020117061157.GA84018>