Conflicting TERM env var with SetEnv feature.

[Nicholas Marriott]

Hi

terminfo and termcap database dissemination times are notoriously slow
so it is common for TERM to be set locally to something that doesn't
exist or doesn't work properly on a remote host.

For many years this was the case with OpenBSD which had ncurses 5.1 and
so an old xterm entry with no colour capabilities; xterm-new was needed
instead. Old versions of Solaris can be as bad if not worse, not to
mention embedded boxes which may have little more than dumb and vt220.

I think it would be 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.


On Fri, Nov 23, 2018 at 10:33:56AM +1030, David Newall wrote:
> On 22/11/18 10:09 pm, Philipp Marek wrote:
> > if it happens that your local terminal emulation is not available
> > on the remote machine(s), what would be the right place to fix it?
> 
> Is it a trick question?  Isn't the remote machine the only place that you
> can fix ?  Setting TERM on the local machine won't magically make a Wyse 60
> understand VT220 control codes.
> 
> Why not wrap ssh with a shell script to do what you want?
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev