Conflicting TERM env var with SetEnv feature.

Raphael Medaer rme at escaux.com
Sat Nov 24 00:22:22 AEDT 2018


TL;DR: I understand TERM is special but ... it should be special in a
sense that **by default** it uses the local TERM value ! Without
overriding it if I intentionally decide to change it in my config.

Jochen Bern, you said:

> distribute something along the lines of (...) into the target accounts'/machines'

IMHO I don't think it's realistic to distribute/install your
"switching TERM procedure" on each remote host. It probably works if
you have 5-10 machines... not with thousands.

As Nicholas Marriott said,

it's
> much more convenient for users with multiple older
> machines to put some Match sections in .ssh/config rather than modifying
> their shell profiles on every host individually or faffing around with
> scripts to wrap ssh.

I fully agree with him. Furthermore, if your TERM is not recognized
remotely, it doesn't mean it is not compatible ! Thank's Gert Doering
for the example of TERM "screen" which can indeed be
substituted/simplified using "xterm". Btw, this is exactly the same
use-case in my first email.

My feeling is that your terminal is living locally on your local
machine. It has its own TERM value with its own feature set. When you
open a session on remote host, you always have the same terminal, with
same feature set. However if this TERM value is not recognized, bad
luck, you cannot use any feature even if a subset of them are
supported (with a compatible TERM value). You probably know that your
remote host is too old, so you should be able to set another
(compatible) TERM.

As far as I know you can do it with following tricks:

 1. Changing your TERM locally then establish your SSH connection
    -> you could automate it with an alias ... but you cannot switch
on target host ...

 2. Establishing your SSH connection and then change your TERM.
    If you do it in the remote shell...
    -> I think it's hard to "automate" when you have a lot of host

    If you do it though an argument of ssh command (for instance `ssh
host 'export TERM=...'`)
    -> I think it's hard to "automate" when you often wrap the ssh command

3. Using SetEnv ?? ... without bug ?

So to answer David Newall:

> Tl;dr: you are right, and TERM is special.

I understand TERM is special but ... it should be special in a sense
that **by default** it uses the local TERM value ! Without overriding
it if I intentionally decide to change it in my config.


More information about the openssh-unix-dev mailing list