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?
>> 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??No. Modern "tmux" has a terminal type "tmux" (similar to screen), but when SSHing into eg. a CentOS7 box this type is not available - and so ncurses things (like an editor) get severely messed up.> Isn't the remote machine the only place that > you can fix ?No. I offered several different ways to deal with that.> ? Setting TERM on the local machine won't magically make > a Wyse 60 understand VT220 control codes.No, but it's the easiest thing to do for mostly-compatible terminals like screen, xterm, tmux, etc.> Why not wrap ssh with a shell script to do what you want?Because that's another point that has to know which machine I deal with. That means argument parsing compatible to SSH, perhaps even knowing about SSH host aliases/redirects via ~/.ssh/config, and so on. Having an SSH "Match" block seems to be the best solution to me, followed by a check in the remote's .bashrc (which would have to be duplicated on all affected hosts, and removed again when an CentOS update allows to use "tmux" there). Furthermore, that "SetEnv" in ssh_config works for all but one environment variable violates the principle of least surprise, and so I'd consider that a bug in SSH. Yeah, $TERM is special - but why not let the user override it?
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
Hi, 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.Stuff like TERM=screen can be substituted reasonably well with TERM=xterm, for example. (I regularily run into this when ssh'ing to AIX boxes, which do not know about "screen" - and since these are not mine, fixing all their termcap/terminfo DBs is not trivially done). So far I've never bothered to look into ssh automatically changing this for me when I ssh to "these boxes", but I'm following the discussion with interest :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany gert at greenie.muc.de
On 11/23/2018 08:15 AM, Gert Doering wrote:> Stuff like TERM=screen can be substituted reasonably well with TERM=xterm, > for example. (I regularily run into this when ssh'ing to AIX boxes, which > do not know about "screen" - and since these are not mine, fixing all their > termcap/terminfo DBs is not trivially done).If the problem is *that* systematic, wouldn't it be a better approach to distribute something along the lines of # Belt&suspenders in case we get executed from a *non*-interactive shell if [ "$TERM" != "" -a "$TERM" != "dumb" ]; then # Doublecheck that the termcap *still* hasn't been updated tput init >/dev/null 2>&1 EXIT=$? if [ $EXIT -ne 0 ]; then # Non-understood $TERM. Try to switch to a working one. # (*This* machine's "working ones" are hardcoded here!) case $TERM in screen) export TERM="xterm" ;; # ... more ... *) export TERM="dumb" ;; esac fi fi into the target accounts'/machines' ~/.bash_profile's, /etc/profile's, /etc/profile.d/TERMfix.sh's, or what-have-you's? Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20181123/92f2f2ef/attachment.p7s>