Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ncar!tank!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: terminfo
Message-ID: <13202@mimsy.UUCP>
Date: 25 Aug 88 07:45:42 GMT
References: <508@altos86.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 73

In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes:
>Why does terminfo exist?

Because the inventor (or at least prime mover: I think Bill Joy had a
hand in the invention) of termcap noticed, after several years, that
termcap was, as a terminal description language, atrocious.

>It makes much more sense to edit a /etc/termcap to install
>new or different terminal capabilities.

I disagree, even though all I have is termcap.

>For what purpose was there created a terminfo.src method
>in which one must edit an ascii file containing the capability
>in question followed by running "tic" on it?

For the same reason that one compiles programs: term(cap|info)
descriptions are used much more often than they are defined.
(Personally, I believe that the overhead in interpreting a single
description, even in the longer terminfo format, is small enough that
interpreting it every time is no loss, and it would get rid of one
serious botch in terminfo: you cannot easily add new capabilities.)

>And why can't terminfo.src have the same syntax and capability strings 
>as /etc/termcap?

Because (he says, entering Ron Natalie mode) the termcap syntax sucks.

>Having each terminal description in a different /usr/lib/terminfo/?/file
>has 2 advantages:
>	1) you can use the filesystem to do ... lookup
>	2) the file can ... be read quicker than parsing some ascii file

Right on both counts.

>The right way to do this sort of thing would be to stick with
>a system based on termcap, but use -ldbm to do hashed lookups
>using a /etc/termcap.{dir,pag} dbm setup.

Well, dbm sucks too.  (Half :-) )  As databases go, its main advantage
is that it is there.

>Having the looked-up data being a ascii string is what I would prefer ....

I agree.

I hear someone asking: `what is wrong with termcap, anyway?'  All
right, quick, tell me how you convert a cursor position to a base 8
one's complement row number offset by ' ' followed by a base 8 one's
complement column number offset by ' ' and occupying two characters
if and only if the value produced is by the first character is >= 95
(in which case the first character is stopped at 95 and the second
is summed into the first, after bit-flipping and converting back from
octal)?

In fact, if you are unlucky enough to have a weird terminal like
the above (whose cm string I made up for illustration, taking the
worst features of two terminals we *do* have and adding a third),
the way you write a cm string is that you edit the termcap library,
adding a new flag, then recompile the library and all of /usr/src.
With terminfo, you write a long and complicated cm string full of
`%' operators, but you do it without having to kludge the source.

(And yes, the one's complement terminals exist: the NIH 7000 is a
modified Delta Data terminal, and we have far too many of them, since
the University got them for a `mere' $200 each when NIH finally threw
them out.  We had to add a `%m' cm capability to cope with the beasts.
The only feature I made up was the base 8 stuff.  GTOMNI, a terminal
emulator [of sorts] for the GT40, requires that the column number
be sent in one character if < 64, else in two.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris