Subject: HEADS UP: change to how TERMCAP is handled
To: None <current-users@netbsd.org>
From: Brett Lymn <blymn@baesystems.com.au>
List: current-users
Date: 05/08/2000 23:07:22
Folks,
        I have just committed a change that modifies the way libterm
handles TERMCAP.  People may or may not be aware that our termcap
library has not had the 1023 byte limitation on it for some time now.
As a backward compatibility feature when the "old" libterm interface
is used (tgetent and friends) the 1023 byte limit is honoured but a
special ZZ capability is added as the last capability in the buffer
that is returned.  This ZZ capability is a string that contains the
memory address of the full, untruncated termcap entry, thus allowing
the full termcap entry to be accessed even if the "old" libterm
interface is used.  Note that the tget* calls automatically use the
untruncated termcap entry, the ZZ capability is there for programmes
that want to parse the buffer themselves.

A problem has arisen with the expansion of the termcap entry.  Some
programmes, such as xterm, take the truncated termcap entry returned
by tgetent and export this into the environment as a TERMCAP
environment variable.  This leads to lossage by curses based
programmes because they get a truncated version of the termcap entry
that may be missing capabilities that would otherwise be utilised.

To fix this problem I have modified libterm so it now checks the
TERMCAP environment variable before it is used.  If TERMCAP contains a
ZZ capability then the entry is deemed suspect and will only be used
iff a termcap entry cannot be found by other means.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================