Mosh: urxvt and Putty Home/End don't work in Mosh

[kmcallister]

urxvt (aka rxvt-unicode) sends CSI7~ and CSI8~ for Home, End respectively.

With TERM=rxvt-unicode, bash will interpret these correctly and jump to the beginning/end of the line.

Screen sets TERM=screen and translates them to CSI1~ and CSI4~, which bash also understands.

But Mosh sets TERM=xterm and does no translation, so bash gets confused.

If I tell urxvt (by X resource) to send CSI1~ then my local bash is confused. If I tell it to use CSIH and CSIF, the Xterm codes, then most things work, but Barnowl doesn't recognize these codes (which could be a Barnowl bug).

I don't know if this is related to #161.

[keithw]

The correct way to solve this may be to place a full UTF8Parser state machine at the client, interpret all the CSIs, and translate "khome" and "kend" (and all the other "k" capabilities) from the user's terminal to xterm sequences.

This seems both like a pain and likely to introduce unpleasantness side effects, but there may be no way around it...

[kmcallister]

If we do client-side parsing for #101, maybe we can do this too.

[keithw]

I thought about this a little more, and I haven't figured out a way to do it that doesn't have the client start depending on the _timing_ of input bytes, which I hate to do.

If we want to capture Putty's ESC [ 1 ~ (khome) and turn it into xterm's ESC O H (khome), we basically have to eat ESC [ and then observe the rest of the escape sequence before printing O H. But I'm not comfortable just eating ESC [ and sitting there indefinitely without printing the [ . On the other hand, I hate the idea of a timeout.

On the third hand, maybe the least bad path is a timeout -- but only when the outer terminal requires this kind of translation (so not for TERM=xterm).

[josch]

until this is fixed, starting mosh inside gnu screen seems to be a workaround (I want to drop neither urxvt nor mosh)

[hexchain]

I had this problem too. Manully exporting TERM=rxvt-unicode-256color on server after connecting makes Home/End keys behave well in applications, but unfortunately not that shell.

Will there be any problem if mosh just passes the client $TERM to server?

[andersk]

Passing TERM to the server is not the right approach; see my comment https://github.com/keithw/mosh/issues/446#issuecomment-20702015.

This needs to be done via translation on the client side in order for the client and server to agree about the state of the terminal at all times. Probably the most clever approach would be to read the client’s terminfo entry and learn the translation automatically from that (like ncurses does).

[keithw]

I don't think this issue (about rxvt cursor-key sequences sent from the terminal to the application) is related to colors (sequences sent from the application to the terminal). Your comment is probably better on issue #557 .

[awwaiid]

All I know is that when I edit src/frontend/mosh-server.cc and s/xterm-256color/rxvt-unicode-256color/ all my home/end issues go away and I don't notice any further issues :) . I guess I need to get the remote system to understand xterm-256color as the "right" solution.

[chandlerc]

Just hit this issue.

I connect with mosh using both xterm and rxvt-unicode and the different escape codes completely hose things. I think that this really needs _some_ solution. I would be happy with either parsing the escape codes or causing the server to be run with the correct TERM...

[txtsd]

mosh incorrectly sets $TERM as xterm-256color while ssh correctly sets it as rxvt-unicode-256color
I have my .zshrc set up with escape sequence hackery to get around this, but it shouldn't be necessary at all.

EDIT: I thought I did. It doesn't work.

[Secretions]

The workaround I'm using for the time being in my .zshrc is checking if TERM is set to xterm*, changing it to rxvt, then doing exec zsh. The exec zsh replaces the current shell with a new instance so the shell itself inherits the TERM variable.

case $TERM in

        xterm)

                export TERM=rxvt

                exec zsh

        ;;

        rxvt-unicode-256color)

                export TERM=rxvt

        ;;

esac

If you try to do something similar, it's absolutely critical that the exec can't get executed on a subsequent run of zsh, or your ability to login via that shell will be completely hosed. Just looking at it causes me anxiety. :)

[grawity]

@Secretions: So why use evil hacks like this at all, rather than setting up the needed keybindings directly? For example:

bindkey '\e[7~' beginning-of-line

[Secretions]

Because, like txtsd, I attempted to setup the keybindings and failed. :)

Looks like the two that are needed are:

bindkey '\e[7~' beginning-of-line
bindkey '\e[8~' end-of-line

Much less insane than what I was doing above. In my first attempt to set the keybindings, I had it in my head to use "^[[1~" and "^[[4~", which was not correct. Thanks.

[cgull]

I'll also point out here that if $PPID is a mosh-server, then it's pretty clear that bindkey is a thing to do. Still a workaround hack, but perhaps a more reliable one that way. Mosh could help children out in a general way with a MOSH_VERSION or similar variable, too.

[Secretions]

Actually, working around the issue with bindkey is resulting in broken home/end when using screen/tmux + any program in the ssh session (ie shell in the screen itself--which would also have the new bindkeys--works, but go into vim or ssh into another server and they stop working). vim/ssh into another server/whatever still have functional home/end after bindkey when not in a screen. Hrm. I may have to take the ride back to crazytown.

[anarcat]

this is really a frustrating bug! i am not sure i am ready to wait another 3 years for this to be fixed, and I don't really understand why TERM is hardcoded to xterm when escapes are passed directly to the terminal without translation. the rationale, as i understand, is that _not_ pretending to be xterm would break expectations, but it seems to me this is _exactly_ what is happening here.

if we could at least _control_ the TERM variable mosh would set, this would be a little more acceptable, but as things stand, i feel mosh brings us back to the horrible confusing of termcaps, terminfos and variable escape sequences which i thought we had escaped from 10 years ago.

for the record, setting TERM=rxvt-unicode here doesn't fix control-arrowkeys (#161) but at least fixes home-end, which makes the pain a little more bearable. i am scared of what else i will find like this however. :/

[The-Compiler]

I don't really understand why TERM is hardcoded to xterm when escapes are passed directly to the terminal without translation.

Because it's not that simple: https://github.com/mobile-shell/mosh/issues/446#issuecomment-20702015

[anarcat]

https://github.com/mobile-shell/mosh/issues/446#issuecomment-20702015 is exactly what i was refering to above. the rationale is "if we pass $TERM along, we get display problems". now the situation is "since we _don't_ pass $TERM along, we get I/O problems".

in other words, passing $TERM along now _fixes_ one problems and has not created new display problems that i can see just yet.

but i'll guess we'll just wait for a state machine to materialize out of thin air now, basically re-incarnating terminfo into a magic cookie. let's just say i'm not holding my breath on that one... :/

[vdrandom]

Maybe mosh itself should translate the input from the terminal a client is being run on into the xterm-capable server? Seems logical to me if it has to use some of the terminal capabilities internally. If you look at tmux / screen, that's what they do: you run them with the correct $TERM, they don't screw up inputs.

I've mostly made some workarounds for it (and frankly, switching the $TERM after connecting to the server made no difference whatsoever, display wise), but encountering this issue over and over again annoys me as well.

[hhirsch]

I have the same issue. It is a dealbreaker for me. I am back to using ssh.

[josch]

@hhirsch in case it helps: I am using mosh like this:

screen mosh me@myserver tmux attach

And my ~/.screenrc has:

escape ""
startup_message off

Which is okay since I normally use tmux for everything. I did not edit any other configuration files.

With this setup I have not yet encountered any issues. I'm using mcabber and irssi inside that tmux session on myserver where I frequently use keys like Home/End and PageUp/PageDown.

[hhirsch]

@josch Well to me this seems like too much trouble to make a square wheel turn.
ssh does not have bugs like this so I just stick to it. If basic stuff like this is broken who knows what else is. I'll try again in 10 years when this issue is fixed.

[tsmithe]

I must also comment that this certainly does not work for me, even using the `screen' trick described above. In particular, I encounter #161. Why does mosh have to emulate a terminal? Why can't it just pass back and forth the byte sequences produced by and for the user's actual terminal?

[andersk]

@tsmithe Mosh relies on a deep understanding of the terminal input and display for its latency reduction tricks. (“But I have a fast network and I don’t need those!” Great, go use SSH then. “But I want Mosh’s automatic roaming!” Well, I sympathize—there’s a place in the world for a version of SSH with just the addition of automatic roaming. But Mosh is not that and cannot reasonably be made into that.)

The screen-in-urxvt workaround does fix the Home/End keys as advertised. It does not help with Ctrl-Arrow keys, but I think that is a screen bug: Ctrl-Arrow keys do not work in screen-in-urxvt even when Mosh is not involved.

[tsmithe]

Interesting; I did not expect that mosh's features depended on such hidden complexity! Thanks for your reply.

I did respect the order for the workaround commands, but with no luck. I will have to investigate more deeply. Should you have any debugging suggestions, I would be glad to hear them, but I suspect I have not provided sufficient detail for that (simply due to ignorance..).

[tsmithe]

EDIT: I may have spoken too soon, but I will return later when I actually get things working fully..

Both fortunately and unfortunately, the best solution I seem to have found for my configuration is to use the urxvt keysym mappings given at http://www.netswarm.net/misc/urxvt-xtermcompat.txt (to simulate an xterm), in conjunction with a local tmux. If I run mosh within that urxvt+xtermcompat+tmux configuration, then I get the expected behaviour remotely: that is, sequences such as Ctrl-Arrow and Home/End work just fine.

Although I can speculate, I am not completely sure why this is -- and why this works whilst other suggestions do not -- but I hope this might be helpful to others.

[anarcat]

@tsmithe that _does_ look like a nasty piece of hack. i wonder what the urxvt people think of _that_ one. ;) does it also work with screen?

[tsmithe]

@anarcat, you are right, it is a nasty hack..

I have found that, with the following .emacs snippet, the xtermcompat hack is unnecessary if I use the screen workaround described above (again, I use tmux for everything, so that's fine). But without this .emacs snippet, I do not get the correct remote behaviour either with the xtermcompat hack, or with the screen workaround. Note that, in both cases (xtermcompat hack, and screen workaround), I find this snippet to be necessary to get the correct remote behaviour in emacs. I am not sure why emacs (24.5.1) needs it!

(global-set-key "\M-[1;5B"    'forward-paragraph)  ; Ctrl+down    => forward paragraph
(global-set-key "\M-[1;5A"    'backward-paragraph) ; Ctrl+up      => backward paragraph
(global-set-key "\M-[1;5C"    'forward-word)       ; Ctrl+right   => forward word
(global-set-key "\M-[1;5D"    'backward-word)      ; Ctrl+left    => backward word
(define-key key-translation-map (kbd "<select>") (kbd "<end>"))

I do not know what the 'select' key is. Running 'read' at the remote end gives me ^[[4~, which is just what I get locally, where there is no `select' problem!

I will add further mappings as and when I find or need them. In particular, I still do not get the right behaviour (seemingly in any case so far!) if I have a local tmux session, with a nested remote tmux session in mosh.

Fundamentally, it just seems like mosh doesn't interpret urxvt I/O correctly, but it does a better job with a client-side tmux session, which in turn does a reasonable job with urxvt... This means that I have a passably working set-up, and can therefore enjoy the many benefits of mosh. These benefits comfortably outweigh the frustrations of these hacks, for now!

EDIT: The solution (for now..) for the nested remote tmux problem was to turn on the xterm-keys tmux option remotely.

[blueyed]

@tsmithe

with the following .emacs snippet, the xtermcompat hack is unnecessary if I use the screen workaround described above

How is this less hackish? :D

[Trollwut]

Little workaound for me was installing rxvt-unicode (which I'm using on my client too) and then putting export TERM=rxvt-unicode into the ~/.bashrc of the user I'm connecting to.

Works for me, even su into another account.

EDIT: before putting that into your bashrc, you can just run echo $TERM to see that it says something xterm. Then running export TERM=rxvt-unicode might fix it. If so, you can put it into your bashrc.

[wilhelmy]

I switched back from tmux to screen for a while (not quite knowing which part of the chain of terminal emulators broke this) because screen apparently translates rxvt keys to xterm keys, while tmux does not. Now I'm back to tmux (because it's just so much nicer) and I would really appreciate if there was a fix for this. Setting TERM=rxvt-unicode-256color for now because it seems like a viable workaround.