On Wed, 31 Jul 1996, Jonathan Stone wrote:

> 
> I should have make it clear that my primary interest is in
> internetworking.  Even a late-1980s telnet can and does automagically
> propagate a TERMCAP string --one *I* can specify -- from my local
> machine to anywhere I choose to telnet.  I don't know any good way to
> do this with terminfo.  If there was a way to do this, I'd be happier
> with terminfo.
> 
> I think it's an issue of control. Who has the opportunity to specify
> what the capabilities of my terminal actually are, given its $TERM
> name: me, or just some remote sysadmin?  Termcap says both
> can. Terminfo says only the latter.  I should've made that distinction
> clear earlier.
> 
> My experience in a university/research environment is that this is a
> real issue, when using telnet or rlogin to some system that doesn't
> have a terminfo or termcap entry for the device I happen to be
> using. There are sysadmins out there that never update whatever
> terminfo/termcap databese the vendor ships.
> 
> If someone wanted to add the ability to parse and use TERMCAP
> environment variables to terminfo, I'd probably be happy to use it.
> The compiler-based terminfo design doesn't seem to make that easily
> doable without burying a termcap-to-terminfo translator *and* a
> terminfo compiler into the terminfo library.
> 
> Is a hashed-termcap-databse-with-4k-buffer completely out of the question?
> Would termcap strings longer than bytes break too many other termcap libraries?
> Unless it's a transient error, the existing pcvt entry seems to suggest not... 

I don't know much about terminfo, but have played with termcap(3,5).
I think termcap is a good system.

Wouldn't an easy solution to this problem be to add a new function to the
termcap interface, which allows one to measure the size of a termcap entry
keyed by the name of the terminal type. Thus, instead of giving a termcap 
routine a 1K buffer, and assuming that the termcap entry is smller than 
1K, one calls a function which determines the size of a termcap entry, 
allocate or declare a buffer of that size, and then call the normal 
routine to fill the buffer out .... ? Or one could just return a pointer 
to allocated memory, and change a pointer to a size_t ...

Increasing the buffer to 4K doesn't seem like a good idea to me, as this 
would probably mean that the same problem would occur again , sometime in 
the future ...


If anyone thinks this is a good idea or has other ideas about this, let 
me know, as I was thinking about fixing/re-writing termcap for my own 
reasons.

Rob C

> 
> --Jonathan
>