Below is a message that I posted to current-users yesterday describing
a change I have made to libterm.  I was driven to do this change
because xterm is biting us hard due to it's habit of exporting the
termcap entry it gets back from tgetent into the environment as a
TERMCAP entry.  Due to the way tgetent works the TERMCAP env variable
is used in preference to anything else.

Since we cannot just return the full termcap entry to the caller of
tgetent if it is over 1024 bytes long (we risk overflowing the buffer)
I was faced with two choices:

1) fix xterm - this can be done but it begs the question of what other
   applications will need fixing.

2) fix libterm to ignore the bogus TERMCAP env variable - if TERMCAP
   has a ZZ capability in it it must be bogus since the contents of
   the ZZ capability is a pointer to memory.  This pointer will be in
   the address space of the process that exported TERMCAP, it makes no
   sense to anyone else.

I chose to implement 2 since, to me, it meant a more generic fix to
the problem.  I acknowledge that it is a hack but I am trying to
nullify the effects of another hack in a manner that fixes the problem
so it won't come back again.

Has anyone a better suggestion for how to fix this problem?

NOTE the tget* routines automatically use the untruncated termcap
entry.  The problem we are facing is, very specifically, TERMCAP
containing the truncated termcap entry.

PS I am not subscribed to this list so please CC me if you want my
input :-)


> 
> 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
===============================================================================