terminfo

[Leslie Mikesell]

In article <212 at alobar.ATT.COM> grs at alobar.att.com (Gregg Siegfried) writes:
>In article <24729 at bu-cs.BU.EDU> madd at bu-it.bu.edu (Jim Frost) writes:
>
>>My vote is against terminfo.  I found several problems with the
>>supplied terminfo entries for the AT&T terminals (4435 I think)
>>attached to 3b2's running SysVr2, as well as on the DMD graphics
                              ^^^^
>No, seriously, if you have the infocmp(1M) program, you can generate the 
>terminfo source from the compiled entry.  You can even generate termcap 
>source from a compiled terminfo entry. 

SysVr2 (at least on 3B2s) did not come with infocmp.  Therefore there
was no way to make a simple fix without re-creating the whole entry.
As I recall, the termcap entries were not necessarily right either,
nor identical to the terminfo entries.

>I don't see it as any less maintainable at all.  The only extra steps in
>reworking a terminfo entry are the infocmp and tic steps.  Otherwise,
>it's exactly the same as modifying a termcap.  Additionally, due to the
>more expressive syntax available with terminfo, it very likely takes
>less time.

Unless you like to do things a step at a time and test them as you
go.  With termcap you could just throw the string into the environment
and run a program.  With terminfo you repeat the compile step for
every change.

I see the inability to use the environment as a real botch in terminfo.
It means that you dedicate a disk block and inode to every terminal type
that might ever be used on a system (including pseudo-terminals provided
in windows by things like emacs).  Also, if it is so flexible, why has it
been necessary to change it with each release of unix since its invention?

Les Mikesell