[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tgetent: warning: termcap entry too long

From: Andy Walker
Subject: Re: tgetent: warning: termcap entry too long
Date: Thu, 19 Feb 2009 10:03:06 -0500

The relavent sections of /etc/termcap appear to be these:

# Entry for an xterm. Insert mode has been disabled.
vs|xterm|xterm-color|vs100|xterm terminal emulator (X Window System):\

# Some other entries for the same xterm.
v2|xterms|vs100s|xterm small window:\
vb|xterm-bold|xterm with bold instead of underline:\
vi|xterm-ins|xterm with insert mode:\

As for ldd:

$ ldd /usr/bin/screen =>  (0xffffe000) => /usr/lib/ (0xb7f2a000) => /lib/ (0xb7f26000) => /lib/ (0xb7ef4000) => /lib/ (0xb7dc1000)
       /lib/ (0x80000000)

On Thu, Feb 19, 2009 at 5:03 AM, Micah Cowan <address@hidden> wrote:
> Andy,
> Does xterm have an entry in your /etc/termcap? Please provide that.
> What do you get for "ldd screen"?
> The thing that bothers me about this, is that the failure point must be
> at screen, rather than the programs running under it, since the kend/kH
> is failing to be translated from \EOF to screen's \E[4~. The only way
> this would make sense to me is if screen is using a real termcap as
> opposed to ncurses' emulation of it through terminfo: real-world termcap
> implementations are known to do things like truncate the entry if it
> exceeds 1023 bytes.
> If the xterm entry in your /etc/termcap is greater than that, and moving
> the definition for kH closer to the top eliminates the problem, then we
> know that termcap is being used (and we need to find out why configure
> is then misdetecting this). Otherwise, it remains a mystery to me why
> \EOF isn't being translated correctly, and no problem with the shells or
> other things running under screen would explain it.
> --
> Micah J. Cowan
> Programmer, musician, typesetting enthusiast, gamer.
> GNU Maintainer: wget, screen, teseq

reply via email to

[Prev in Thread] Current Thread [Next in Thread]