Terminfo()--Ideas needed. System V

[Bennett E. Todd III]

In article <2146 at cbosgd.UUCP> mark at cbosgd.UUCP writes:
>In order to compare the difference between termcap and terminfo with
>something we are all more familiar with, I'm paraphrasing Mr. Todd's
>posting, substuting a different example.  Let's compare C (a compiled
>language) with shell (an interpreted language) and observe that binary
>versions of UNIX still have readable (and editable) shell scripts.

(followed by my complaints about terminfo, with the described
substitutions)

Not bad! Made me think for a bit. However, as you say, "binary versions
of UNIX still have [...] shell scripts." Quite true. There are good
reasons why shell scripts are better suited to some applications than C
programs, and vice versa. Shell scripts are readily customizable; they
take less space; shell scripts are the appropriate language when all
that is desired is some straightforward combination of existing tools.

Compiled C programs are better suited to some applications. They
generally run much faster; they have ready access to all the system
calls; and C is a better language for expressing complex data structures
(and, to a lesser degree, algorithms).

However, the analogy isn't exact. Specifically, there is a tradeoff that
must be addressed whenever one is deciding on a database organization:
will you use a compiled (packed) binary representation, saving time when
reading the database, or will you use a straight (ideally reasonably
free-form) textual format, preserving the usefulness of the large
assortment of UNIX tools which assist in manipulating files of textual
data?

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. 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.

Quite a few people have suggested I look up the infocmp utility and go
away. Probably, if I had one, I'd never have been so preturbed about the
intrinsic loss of flexibility that comes with a binary representation to
have posted a gripe to the net. However, AT&T has shipped far too many
UNIX's (including all the System V's I've gotten a crack at) *without*
infocmp for that to be terribly persuasive.

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. If you are out to obstruct people
trying to do new and interesting things, then by all means take every
step available to encode any datafiles in the most intractable fashion
available -- and don't try to sell me your product. As I said, terminfo
is more expressive than termcap; that, however, is unrelated to the
compilation of the terminfo descriptions, and isn't anything that
couldn't be added to termcap. Hell, I am not wedded to /etc/termcap
format inextricably; if we had /etc/terminfo with the source forms of
terminfo descriptions, and if that's what the terminfo library worked
from, then I'd have no serious complaints (except for the gratuitous
incompatability of formats, which might be justifiable given how much
nicer terminfo's is). But encoding the source description in a binary
format buys you nothing that cannot be gotten in less obstructive ways.

-Bennett
-- 

Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet