Freebsd 14+ -- tcsh incompatible with terminfo

12 views
Skip to first unread message

Jamie Landeg-Jones

unread,
Oct 31, 2023, 6:45:58 PM10/31/23
to ba...@freebsd.org, freebsd...@freebsd.org
Hi!

The changes to FreeBSD base ncurses to use the terminfo db over termcap if it
exists have caused a few issues with tcsh, which doesn't seem to grok terminfo.

e.g. : install misc-terminfo

switch to tcsh, and reinitialise terminal information:

% setenv TERM dumb
% setenv TERM xterm
% echotc AF 1
echotc: `AF' requires 2 arguments.

Deleting the relevent terminfo entry, and reinitialising the terminal information
causes everything to work again.

Tested on stock 14.0-RC3

I have some other locally grown stuff that complains for similar reasons, that
I'll have to fix too, but in the meantime, what's the easiest way to force any
program to use termcap over terminfo rather than the other way around, or is
this the wrong approach?

I considered kludging with environment variables TERMINFO/TERMCAP, but these
are login based rather than program based, and if instead set inside a program,
could cause spawned programs to also be polluted, if not careful, especially
with a shell.

Cheers, Jamie

Jamie Landeg-Jones

unread,
Oct 31, 2023, 7:00:14 PM10/31/23
to ja...@catflap.org, freebsd...@freebsd.org, ba...@freebsd.org
Jamie Landeg-Jones <ja...@catflap.org> wrote:

> switch to tcsh, and reinitialise terminal information:
>
> % setenv TERM dumb
> % setenv TERM xterm

% setenv TERM xterm-256color

Apologies, it seems this doesn't affect plain "xterm", but it does at least
affect xterm-16color and xterm-256color.

Is this, therefore, a terminfo.db issue?

Thanks again, Jamie

Thomas Dickey

unread,
Oct 31, 2023, 8:18:40 PM10/31/23
to Jamie Landeg-Jones, freebsd...@freebsd.org, ba...@freebsd.org
On Tue, Oct 31, 2023 at 10:59:48PM +0000, Jamie Landeg-Jones wrote:
> Jamie Landeg-Jones <ja...@catflap.org> wrote:
>
> > switch to tcsh, and reinitialise terminal information:
> >
> > % setenv TERM dumb
> > % setenv TERM xterm
>
> % setenv TERM xterm-256color
>
> Apologies, it seems this doesn't affect plain "xterm", but it does at least
> affect xterm-16color and xterm-256color.

actually it probably does affect "xterm"

Checking the source, tcsh is expecting a termcap string, while data read
from the terminfo database is going to be in terminfo format -- even if
read via tgetent/tgetstr

tcsh is expecting a termcap string, and in its EchoTC function it duplicates
the termcap version of what's tparm in a terminfo program.

(tcsh could be modified readily to use terminfo for the case you're describing,
but supporting $TERMCAP would be work)

> Is this, therefore, a terminfo.db issue?
>
> Thanks again, Jamie
>

--
Thomas E. Dickey <dic...@invisible-island.net>
https://invisible-island.net
signature.asc

Jamie Landeg-Jones

unread,
Oct 31, 2023, 11:50:19 PM10/31/23
to ja...@catflap.org, dic...@his.com, freebsd...@freebsd.org, ba...@freebsd.org
Thomas Dickey <dic...@his.com> wrote:

> actually it probably does affect "xterm"
>
> Checking the source, tcsh is expecting a termcap string, while data read
> from the terminfo database is going to be in terminfo format -- even if
> read via tgetent/tgetstr
>
> tcsh is expecting a termcap string, and in its EchoTC function it duplicates
> the termcap version of what's tparm in a terminfo program.
>
> (tcsh could be modified readily to use terminfo for the case you're describing,
> but supporting $TERMCAP would be work)

Hi Thomas, thanks for the reply... from the ncurses man himself!

I *thought* I'd seen issues with just "xterm" but after posting the first
message, it seemed to start working, and so I doubted myself, but I must
have messed up somewhere!

What threw me about tcsh is it does mention terminfo in the man page and
the source, so I wrongly assumed the problem wasn't there.

Anyway, I'll raise it with the tcsh maintainers.

To the FreeBSD release folk, I think it's great that we're moving off termcap,
but is there a chance that base tcsh could be compiled with a private version
of the terminfo-less ncurses in time for 14.0-RELEASE, if a proper fix to tcsh
is going to take too long?

Thanks again, Thomas.

Cheers, Jamie

Thomas Dickey

unread,
Nov 2, 2023, 9:09:03 PM11/2/23
to Jamie Landeg-Jones, freebsd...@freebsd.org, dic...@his.com, ba...@freebsd.org
On Thu, Nov 02, 2023 at 06:58:55PM +0100, Steffen Nurpmeso wrote:
> I do understand that a bit. Other than that plain termcap was so
> small and i would assume essentially unchanged for decades, that
> i do not. Termcap entries, yes. I could imagine vt220, xterm,
> screen-256color, and take one of st-256color, whatever KDE and
> GNOME terminal, and rxvt-unicode. Makes seven. Likely
> automatically extractable via "infocmp -C" of Dickey's terminfo.
>
> Let's just try that:
>
> $ rm .TCAP;\
> for f in vt220 xterm screen-256color st-256color \
> rxvt-256color gnome-256color konsole-256color; do \
> infocmp -C $f >> .TCAP;\
> done;\
> ls -l .TCAP
> -rw-r----- 1 steffen steffen 7145 Nov 2 18:40 .TCAP

There's more data in termcap than that (which some people would like to use).
And there's additional data for terminfo -- again, some want it.

man infocmp:

For best results when converting to termcap format, you should use both
-C and -r. Normally a termcap description is limited to 1023 bytes.
infocmp trims away less essential parts to make it fit. If you are
converting to one of the (rare) termcap implementations which accept an
unlimited size of termcap, you may want to add the -T option. More of‐
ten however, you must help the termcap implementation, and trim excess
whitespace (use the -0 option for that).

(-T is appropriate here - ymmv)

With -C alone, I get
-rw------- 1 tom users 7315 Nov 2 21:02 .TCAP

With -CrT,
-rw------- 1 tom users 14390 Nov 2 21:02 .TCAP

For terminfo, no options
-rw------- 1 tom users 16027 Nov 2 21:03 .TCAP

For terminfo with -x
-rw------- 1 tom users 19533 Nov 2 21:03 .TCAP
signature.asc
Reply all
Reply to author
Forward
0 new messages