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 #446 (comment).

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...