terminfo
Donn Baumgartner
donn at r2d2.ACA.MCC.COM
Fri Sep 2 04:49:29 AEST 1988
In article <8412 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <1553 at mcgp1.UUCP> fst at mcgp1.UUCP (Skip Tavakkolian) writes:
>-In article <8377 at smoke.ARPA>, gwyn at smoke.ARPA (Doug Gwyn ) writes:
>-> In article <508 at altos86.UUCP> clp at altos86.UUCP (Chuck L. Peterson) writes:
>-> >Why does terminfo exist?
>-> Because termcap was too limited.
>-Please explain.
> :
> :
> :
This is ridiculous... if termcap had been 'supported' (in any real sense of
the word), I doubt if there would be a terminfo... and if terminfo isn't
supported any better than termcap was/is, there will be yet another 'standard'
(if you can believe that two can be standard... sigh).
(confession follows:) Years ago I extended Ken Arnold's version of curses
for the IBM RT project to add support for multiple character attributes,
fonts, colors, international languages, and box drawing (using box characters)
- as well as bug fixes, etc. (And remnants of this can still be seen in AIX).
But needless to say, this added support required additions to termcap (keep
in mind that this was all taking place at the same time as Mark Horton was
writing terminfo and the new curses). So, after much studying, I added all
the necessary codes to termcap (like I said, AIX still uses these...).
But I knew this was not enough, so I submitted these to termcap at berkeley so
that they might actually become part of 'the standard'. Fat chance! The
persons responsible for handling termcap at berkeley were apparently seriously
overworked, and as such, just not very interested... the response alone took
something like 6 months to come back(!).
My basic contention here is that there wasn't *really* a need for an entirely
new version of a terminal capabilities database... just a little support and
maintenance for the existing version. All the complaints I've ever heard
about termcap (which are typically used as justification for the existence of
terminfo) can (and should) be fixed in termcap. Want more support for
'whatever'? - fine, add (or fix existing!) codes to termcap. Termcap is too
slow? - fine, add an index at the start of the file (termcap is, after all, a
database, right?), and make the index look like a termcap entry so as not to
break old software (and etc.). No matter what the complaint, if terminfo can
fix it, it can and could be fixed in termcap (by someone sufficiently
interested in such).
Don't get me wrong, although I think terminfo was unnecessary, it's not that
I have anything against it... afterall, it does provide termcap capatibility
codes for everything (which I promptly snarf-up and add to my termcap and
curses routines :-). And (gosh...) this is like so many other things in the
unix world... someone says "this isn't good enough", and they throw out the
baby with the bath water. (I kind of like Columbia's approach to 'kermit'...
when it needs fixing, they do... and they release another version - not an
entirely new and incompatible program.)
I've seen some vendors (names left out to keep the flames down) actually
support their software... but it takes some amount of 'guts'... because
fixing your software means admitting it was buggy (or insufficient) in the
beginning. A lot of the new public domain software has gone this way...
maybe the rest will follow. [end of religious rampage]
- Donn Baumgartner
_
( )
\___|___/ Fear no Evil!
|
| Just wanna Skate...
/ \
__/ \__ Skate (Free) or Die!
oo oo
More information about the Comp.unix.wizards
mailing list