Re: [tlug] vi weird when I ssh to one machine

["Stephen J. Turnbull" <turnbull@example.com>]

First, thanks to Scott for confirming that it happens to him too, and
for providing the empty TERM value.

I wonder if the problem here is that TERM is set but not exported when
the local shell is run.  Then the local tty and shell see TERM, but
SSH won't, soi the remote will have to guess (ie, use a default).  A
conservative default would be a line printer which only understands
CRLF :-), but I wouldn't be surprised if some systems default to VT100
or xterm.  That would help explain Darren getting uninterpreted
control sequences, assuming the local curses defaults to an
appropriate termcap (the modern version is terminfo, but I'm a
traditionalist :-) when TERM is unset.  However, if the remote default
is at all sane (ie, at most VT100), pretty much all modern terminals
understand that.  So this seems unlikely to be a full explanation.

Jens John writes:

 > [T]he important thing is that the termcap description file for
 > whatever value TERM has is present both on the remote server and
 > the client for things to work out correctly.

Thank you, this is exactly right.

Note, I don't know of any terminals (not even Emacs) that reconfigure
themselves based on a termcap file.  The terminal dictates the escape
codes it understands and produces based on its firmware or hardcoded
emulation.  It's the applications programs that use curses and the
termcap file.  Anyway, Darren's not having a problem with the local
shell, so local curses has access to a usable termcap for whatever the
local terminal is.  Not clear to me why the local curses gets that
termcap when SSH sees an empty TERM, though.  See above for a possible
explanation.

 > This is another thing to check, because curses and similar
 > libraries will output escape sequences based on the termcap
 > description only.

I'm going to omit your excellent explanation since it's not really
relevant to the diagnosis.

I think it's more subtle than a missing termcap.  As the fragment
component of the URL you provide[1] indicates, you're likely to be
unable to open the remote shell at all, or get an error message in the
case of a missing termcap.  But Darren didn't report either of those,
so apparently the remote does have a termcap it's using.

What I suspect may be happening with Darren is either an insanely
overaggressive remote default for TERM, or (since he said the remote
is set up as a workstation) that the termcap itself is wrong.
Specifically, I've seen systems where xterm is an alias for xterm-256
(256-color xterm; traditional xterms can do at most 16 colors) or
uxterm (an xterm that assumes the remote charset is UTF-8).  I'm not
sure what happens if a program tries to use 256 colors in a
traditional xterm, but knowing the X programmers, I'm pretty sure it's
not good. ;-)  I think we all know what happens if a program sends JIS
to a uxterm.

Finally, a really exotic possibility is that the correct TERM is sent,
but the remote thinks that the local xterm is in Tektronix (bitmap
graphics emulation) mode.  That would be a mess!

Anyway, I'm curious to see how close all our guesswork comes!

 > [1] https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the-terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a-different-computer