Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2171@cbosgd.UUCP>
Date: Tue, 27-May-86 01:08:33 EDT
Article-I.D.: cbosgd.2171
Posted: Tue May 27 01:08:33 1986
Date-Received: Wed, 28-May-86 01:45:13 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <1553@ecsvax.UUCP> <2146@cbosgd.UUCP> <1596@ecsvax.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 66
Keywords: terminfo,termcap
Xref: watmath net.unix-wizards:18211 net.unix:7979 net.info-terms:998

In article <1596@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes:
>The case of terminal descriptions seems like a middle ground -- people
>have different views. Termcap has the benefits of a readble database
>format. Terminfo is faster in the worst case. How often do you access
>every term[(cap)|info)] description? Not in the lifetime of most UNIX
>systems, I'd imagine.

It's quite true that the analogy isn't exact.  In particular, there are
gobs of applications where shell is more appropriate than C.  From my
experience, I have run across only a single application where termcap
is more appropriate than terminfo.

By the way, I stated earlier that termcap was more convenient for a
development environment.  What I meant was an environment where termcap
or terminfo descriptions are being developed.  If you're developing
something else, then you have a production environment as far as
termcap/terminfo is concerned.

>A termcap database sorted approximately in
>decreasing order of frequency of use should be at least as fast as the
>repeated directory lookups required to descend the terminfo tree -- and
>termcap format is *trivial* to parse.
>
>If speed is what you want, sort /etc/termcap in decreasing order of
>frequency of use. If that's not good enough for you, cram your termcap
>definition in the environment variable TERMCAP and leave terminfo behind
>entirely, when it comes to speed.

I used to think this too.  I was at Berkeley when we decided how to sort
termcap files and put them into the environment.  It helped a lot.

But it turns out that even if you put a termcap in your environment,
it's still too slow.  The termcap algorithm for reading the entry
into a set of capabilities is QUADRATIC on the size of the entry.
This is the nature of the beast - because of tc=, you have to start
from the left for each capability search.  As termcap descriptions got
longer, starting up vi grew slower and slower.  It was taking 1/4 second
of CPU time on a VAX 750 to parse the termcap entry, even when it came
out of the environment.

This was when I decided to move to a compiled format.  Things get much
simpler for the typical user - no need for the whole entry in the
environment anymore, or the hair of tset -s in the .profile/.login.
The ps command was breaking from the huge environment entries that
took the arguments off the top page of memory.  Forks were expensive.
And it took too long to start up vi.  All these problems went away
when terminfo was compiled.

Termcap format is trivial to parse, IF you are willing to put up with
some of the disadvantages of interpreters, such as no error messages,
slow speed, and the size of the parser.  If you wanted to get good
error messages, termcap would be as hard to parse as terminfo.  (For
those who are not impressed with tic's error messages, the SVr2 tic,
which was frozen for SVr2 in April 1983 along with the rest of curses,
is essentially the termcap parser.  The SVr3 tic is completely redone,
by Pavel Curtis, and it's as fussy as pcc.)

And I'm sorry you can't get SVr3 yet, and that in the meantime you're
all using 3 year old code.  We don't control the release dates, and
curses hasn't been what's holding up SVr3.  You might look to see if
you got the "ti4" program with SVr2, which dumps out a terminfo binary,
although not in tic-readable form.  I think it was in the source dir
but not normally installed.  It's the only tool we had for printing
out the binaries back in 1983.

	Mark