I have a situation where I am ssh'ing from a Linux machine running a
relatively new (Debian flavored) distro to another machine running an older
version of the same distro. The TERM on the ssh'ing machine is
tmux-256color, so when it ssh's to the other machine, it picks up this
value for TERM. The problem is that that file doesn't exist on the older
machine. So, the result is that whenever I run a ncurses based program
(the main two of interest here are "less" and "vi" (vim)), I get a warning
message saying something like "WARNING: terminal is not fully capable" (or
something like that...). And, the screen display (particularly in less) is
not quite right.

So, I figure "No problem"; I'll just copy over the terminfo file from the
new machine to the old machine. So, I copy /usr/share/terminfo/t/tmux-256color
to the same place on the old machine. But then, the error message doesn't
go away and the basic problem does not go away. So, for some reason, it
doesn't like the new file. I know I've done this sort of thing in the past
and it has worked, but for some reason, it isn't working here.

So, the first thing that pops into my mind is: Is there some kind of
database of all the terminfo files - some sort of registry - such that just
putting the file there isn't enough? Do you have to tell some database
that a new file is there? I don't recall having to do that in the past,
but you never know...

Another thing to note is that I get exactly the same warning message if I
set TERM to something that doesn't exist (E.g., TERM=garbage) as I do
when it is set to tmux-256color. It'd be nice if it was more explicit
about what the problem is.

Note, BTW, that setting TERM=screen (after logging into the old machine)
does work, but this is somewhat suboptimal.

P.S. And, yes, you can infer from this text that somehow, the "tmux"
program is involved.

--
Every time a Republican gets caught doing something illegal (i.e., just about every
day or two), they always immediately issue two simultaneous statements about it:
1) "I didn't do it" (Standard denial, which of course only cult-members pay any attention to)
2) "Here's how I did it and why I did it and why it shouldn't matter to you and why you should go back to watching sports on TV"

gazelle@shell.xmission.com (Kenny McCormack) writes:
>I have a situation where I am ssh'ing from a Linux machine running a
>relatively new (Debian flavored) distro to another machine running an older
>version of the same distro. The TERM on the ssh'ing machine is
>tmux-256color, so when it ssh's to the other machine, it picks up this
>value for TERM. The problem is that that file doesn't exist on the older
>machine. So, the result is that whenever I run a ncurses based program
>(the main two of interest here are "less" and "vi" (vim)), I get a warning
>message saying something like "WARNING: terminal is not fully capable" (or
>something like that...). And, the screen display (particularly in less) is
>not quite right.
>
>So, I figure "No problem"; I'll just copy over the terminfo file from the
>new machine to the old machine. So, I copy /usr/share/terminfo/t/tmux-256color
>to the same place on the old machine. But then, the error message doesn't
>go away and the basic problem does not go away. So, for some reason, it
>doesn't like the new file. I know I've done this sort of thing in the past
>and it has worked, but for some reason, it isn't working here.

On the source machine, use 'infocmp' to print out the terminal
description. On the destination machine feed that description
to the 'tic' command.

In article <YcF3P.41752$tKZd.16879@fx18.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
....
>On the source machine, use 'infocmp' to print out the terminal
>description. On the destination machine feed that description
>to the 'tic' command.

Bingo! Thanks.

I knew about "tic" (in theory at least). Didn't really know about "infocmp".

I was impressed that "tic" did exactly the right thing. It created the
directory ~/.terminfo/t and put the compiled file there, w/o my having to
specify it. I assumed it would just write to standard output (like most
programs do), but such is not the case.

So, the takeaway is that, as is usually the case in Linux, "terminfo" is
source code portable/compatible, but not binary compatible.

--
One should not believe everything posted to USENET.

- Aharon (Arnold) Robbins arnold AT skeeve DOT com -
- 4/15/19 -

On 2024-12-03, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> I have a situation where I am ssh'ing from a Linux machine running a
> relatively new (Debian flavored) distro to another machine running an older
> version of the same distro. The TERM on the ssh'ing machine is
> tmux-256color, so when it ssh's to the other machine, it picks up this
> value for TERM. The problem is that that file doesn't exist on the older
> machine. So, the result is that whenever I run a ncurses based program
> (the main two of interest here are "less" and "vi" (vim)), I get a warning
> message saying something like "WARNING: terminal is not fully capable" (or
> something like that...). And, the screen display (particularly in less) is
> not quite right.

tmux-256color *must* be compatible (or at least largely compatible) with
other 256 color extensions to ANSI like xterm-256color, so try that.

Find whatever "256 color" thing the machine's termcap does understand.

Failing that, use TERM=ansi, and in the vanishingly improbable case that
doesn't work, TERM=vt100.

> So, I figure "No problem"; I'll just copy over the terminfo file from the
> new machine to the old machine. So, I copy /usr/share/terminfo/t/tmux-256color
> to the same place on the old machine. But then, the error message doesn't
> go away and the basic problem does not go away. So, for some reason, it
> doesn't like the new file. I know I've done this sort of thing in the past
> and it has worked, but for some reason, it isn't working here.

"terminfo" consists of binary data which is not standardized. There
are different implementations of it. See Terminfo page in Wikipedia etc.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <20241203093857.631@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
....
>"terminfo" consists of binary data which is not standardized. There
>are different implementations of it. See Terminfo page in Wikipedia etc.

Like I said, it is only compatible at the source code level.

But I like what you said about there being different implementations of it.

--
People sleep peaceably in their beds at night only because rough
men stand ready to do violence on their behalf.

George Orwell

On 2024-12-03, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20241203093857.631@kylheku.com>,
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> ...
>>"terminfo" consists of binary data which is not standardized. There
>>are different implementations of it. See Terminfo page in Wikipedia etc.
>
> Like I said, it is only compatible at the source code level.
>
> But I like what you said about there being different implementations of it.

On a tangent related to this, all new programs should just use ANSI
escape sequences directly and not rely on the terminfo crap.

If you need complex screen control, you probably do want curses and so
you can't get away from the dependency. But for anything simple, just
use the ANSI/ECMA standard terminal control we have had since 1976.

I used to do remote work using an amber screen WYSE 50, coupled to a US
Robotics 14.4 kbps modem. Even then, I was a lunatic. The terminal was
a discard from a public library; even that institution had moved on from
it already and they are not exactly known to be early adopters of tech.
Those days are long gone. (I mean I'm still a lunatic, so that aspect
of those days is not gone).

terminfo is mainly something we have to carry in distros for the sake of
retrocomputing enthusiasts. It's like gas stations having to provide
leaded gas for the odd customer who drives in with a 1930's
Ford Model T.

We could use a curses library that has ANSI hardcoded in it, opening no
database at all, with API support for some popular extensions like
color.

How about a fork of ncurses which turns a tiny, cherry-picked subset of
the terminfo database into a binary blob that is built into the library
itself.

Just my daily hot take.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca