cursor keys work outside but not inside of tmux with Putty, TERM=putty-256color

[mbunkus]

I'm using Putty to ssh from Windows to my Arch Linux server. There I'm currently running tmux 2.3.1, ncurses 6.0+20161224-1.

In order to use 256 colors I've instructed Putty to set TERM=putty-256color. I have confirmed that the variable is set as shown directly after having logged in.

My problem is that the left & right cursor keys don't work in cat and zsh within tmux whereas cursor up/down do work. My second problem is that inside tmux Ctrl+cursor… produces exactly the same sequence as cursor… (without Ctrl). I've confirmed that this happens with a completely new user account wihtout any tmux configuration, with an empty $HOME.

This used to work one of these days, and I cannot pinpoint where the problem comes from.

How to reproduce:

• Get Putty
• Configure Putty to set putty-256color as TERM
• Log in to an up-to-date Arch Linux
• Run cat outside tmux and press some cursor keys
• Start tmux in its default configuration wihtout a user configuration
• Run cat inside tmux and press the same cursor keys
• Observe the behavior described above
• Quit cat, enter a couple of keys in the shell and press left/right cursor keys and observe that the cursor doesn't move at all

Here's the output of cat outside of tmux. The first line: cursor keys up, down, left, right without modifiers, followed by enter. The third line: Ctrl+cursor up, down, left, right, followed by enter. Fith line: Alt+cursor up, down, left, right, followed by enter.

sweet-chili% cat
^[[A^[[B^[[D^[[C

^[OA^[OB^[OD^[OC
ABDC
^[^[[A^[^[[B^[^[[D^[^[[C

Here's the output of cat inside of tmux. The same keys are pressed in the same order as before. The first line: cursor keys up, down, left, right without modifiers, followed by enter. The third line: Ctrl+cursor up, down, left, right, followed by enter. Fith line: Alt+cursor up, down, left, right, followed by enter.

sweet-chili% cat
^[[A^[[B

^[[A^[[B^[[D^[[C

^[^[[A^[^[[B

Here's the tmux-server.log from said new user account in which I've created the second cat sequence shown above.

I'll be happy to provide more information, to test things etc., but I definitely need help as I cannot figure out how to proceed, how to debug this further, let alone how to fix it. Thanks.

[nicm]

The reason your Left and Right keys don't work at all is because tmux thinks these sequences mean S-Left and S-Right: 1483474769.984516 replacing key \033[D: 0x900000000043 (S-Left) 1483474769.984519 replacing key \033[C: 0x900000000044 (S-Right) I think this is a problem in the putty-256color entry: $ TERM=putty-256color tput kLFT|cat -v ^[[D putty normally generates \033OD for Left, but when Shift is pressed it generates \033[D. However, it swaps them around when cursor keys mode is enabled (which tmux uses), so tmux is expecting the wrong escape sequences. The best thing to do here is to just remove the Shift variants with terminal overrides, something like: set -ag terminal-overrides ',putty*:kLFT@:kRIT@' It looks to me from your example like putty doesn't generate a unique escape sequence for the Ctrl keys, so you won't be able to use them with tmux or any application.

…

On Tue, Jan 03, 2017 at 12:26:33PM -0800, Moritz Bunkus wrote: I'm using Putty to ssh from Windows to my Arch Linux server. There I'm currently running tmux 2.3.1, ncurses 6.0+20161224-1. In order to use 256 colors I've instructed Putty to set TERM=putty-256color. I have confirmed that the variable is set as shown directly after having logged in. My problem is that the left & right cursor keys don't work in cat and zsh within tmux whereas cursor up/down do work. My second problem is that inside tmux Ctrl+cursor*** produces exactly the same sequence as cursor*** (without Ctrl). I've confirmed that this happens with a completely new user account wihtout any tmux configuration, with an empty $HOME. This used to work one of these days, and I cannot pinpoint where the problem comes from. How to reproduce: * Get Putty * Configure Putty to set putty-256color as TERM * Log in to an up-to-date Arch Linux * Run cat outside tmux and press some cursor keys * Start tmux in its default configuration wihtout a user configuration * Run cat inside tmux and press the same cursor keys * Observe the behavior described above * Quit cat, enter a couple of keys in the shell and press left/right cursor keys and observe that the cursor doesn't move at all Here's the output of cat outside of tmux. The first line: cursor keys up, down, left, right without modifiers, followed by enter. The third line: Ctrl+cursor up, down, left, right, followed by enter. Fith line: Alt+cursor up, down, left, right, followed by enter. sweet-chili% cat ^[[A^[[B^[[D^[[C ^[OA^[OB^[OD^[OC ABDC ^[^[[A^[^[[B^[^[[D^[^[[C Here's the output of cat inside of tmux. The same keys are pressed in the same order as before. The first line: cursor keys up, down, left, right without modifiers, followed by enter. The third line: Ctrl+cursor up, down, left, right, followed by enter. Fith line: Alt+cursor up, down, left, right, followed by enter. sweet-chili% cat ^[[A^[[B ^[[A^[[B^[[D^[[C ^[^[[A^[^[[B Here's the [1]tmux-server.log from said new user account in which I've created the second cat sequence shown above. I'll be happy to provide more information, to test things etc., but I definitely need help as I cannot figure out how to proceed, how to debug this further, let alone how to fix it. Thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly, [2]view it on GitHub, or [3]mute the thread. Reverse link: [4]unknown References Visible links 1. https://gist.github.com/mbunkus/2f4e88e2769f1e505c04ed4b7ba4b533 2. #708 3. https://github.com/notifications/unsubscribe-auth/AASkc-uDyg3PDT4NXReQcpVB8xKtJmTKks5rOq75gaJpZM4LZ_h4 4. #708

[nicm]

Oh, you might be saying the C-Left generates \033OA. Perhaps it does, if so then you can tell tmux about it by adding kLFT5, kRIT5, kUP5, kDN5 with terminal-overrides: set -as terminal-overrides ',putty*:kLFT5=\EOA' (It should be -as not -ag but both should work from .tmux.conf). My memory of putty is that it is \033OA for Left, \033[A for S-Left, and the terminfo entry says the same. But perhaps you can make it send \033OA for C-Left. You will probably also need to turn on xterm-keys to make tmux generate these keys for applications inside, and you may need a custom terminfo entry to use inside tmux: cat <<EOF|tic -x - tmux|tmux terminal multiplexer, ritm=\E[23m, rmso=\E[27m, sitm=\E[3m, smso=\E[7m, Ms@, use=xterm+pcfkeys, use=xterm+sl, use=xterm+tmux, use=screen, tmux-256color|tmux with 256 colors, use=xterm+256setaf, use=tmux, EOF

…

On Tue, Jan 03, 2017 at 11:40:13PM +0000, Nicholas Marriott wrote: The reason your Left and Right keys don't work at all is because tmux thinks these sequences mean S-Left and S-Right: 1483474769.984516 replacing key \033[D: 0x900000000043 (S-Left) 1483474769.984519 replacing key \033[C: 0x900000000044 (S-Right) I think this is a problem in the putty-256color entry: $ TERM=putty-256color tput kLFT|cat -v ^[[D putty normally generates \033OD for Left, but when Shift is pressed it generates \033[D. However, it swaps them around when cursor keys mode is enabled (which tmux uses), so tmux is expecting the wrong escape sequences. The best thing to do here is to just remove the Shift variants with terminal overrides, something like: set -ag terminal-overrides ',putty*:kLFT@:kRIT@' It looks to me from your example like putty doesn't generate a unique escape sequence for the Ctrl keys, so you won't be able to use them with tmux or any application. On Tue, Jan 03, 2017 at 12:26:33PM -0800, Moritz Bunkus wrote: > I'm using Putty to ssh from Windows to my Arch Linux server. There I'm > currently running tmux 2.3.1, ncurses 6.0+20161224-1. > > In order to use 256 colors I've instructed Putty to set > TERM=putty-256color. I have confirmed that the variable is set as shown > directly after having logged in. > > My problem is that the left & right cursor keys don't work in cat and zsh > within tmux whereas cursor up/down do work. My second problem is that > inside tmux Ctrl+cursor*** produces exactly the same sequence as cursor*** > (without Ctrl). I've confirmed that this happens with a completely new > user account wihtout any tmux configuration, with an empty $HOME. > > This used to work one of these days, and I cannot pinpoint where the > problem comes from. > > How to reproduce: > > * Get Putty > * Configure Putty to set putty-256color as TERM > * Log in to an up-to-date Arch Linux > * Run cat outside tmux and press some cursor keys > * Start tmux in its default configuration wihtout a user configuration > * Run cat inside tmux and press the same cursor keys > * Observe the behavior described above > * Quit cat, enter a couple of keys in the shell and press left/right > cursor keys and observe that the cursor doesn't move at all > > Here's the output of cat outside of tmux. The first line: cursor keys up, > down, left, right without modifiers, followed by enter. The third line: > Ctrl+cursor up, down, left, right, followed by enter. Fith line: > Alt+cursor up, down, left, right, followed by enter. > > sweet-chili% cat > ^[[A^[[B^[[D^[[C > > ^[OA^[OB^[OD^[OC > ABDC > ^[^[[A^[^[[B^[^[[D^[^[[C > > Here's the output of cat inside of tmux. The same keys are pressed in the > same order as before. The first line: cursor keys up, down, left, right > without modifiers, followed by enter. The third line: Ctrl+cursor up, > down, left, right, followed by enter. Fith line: Alt+cursor up, down, > left, right, followed by enter. > > sweet-chili% cat > ^[[A^[[B > > ^[[A^[[B^[[D^[[C > > ^[^[[A^[^[[B > > > Here's the [1]tmux-server.log from said new user account in which I've > created the second cat sequence shown above. > > I'll be happy to provide more information, to test things etc., but I > definitely need help as I cannot figure out how to proceed, how to debug > this further, let alone how to fix it. Thanks. > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly, [2]view it on GitHub, or [3]mute the thread. > > Reverse link: [4]unknown > > References > > Visible links > 1. https://gist.github.com/mbunkus/2f4e88e2769f1e505c04ed4b7ba4b533 > 2. #708 > 3. https://github.com/notifications/unsubscribe-auth/AASkc-uDyg3PDT4NXReQcpVB8xKtJmTKks5rOq75gaJpZM4LZ_h4 > 4. #708

[mbunkus]

Thank you very much! This helps me a lot & I'll give the workarounds a try.

My memory of putty is that it is \033OA for Left, \033[A for S-Left, and the terminfo entry says the same. But perhaps you can make it send \033OA for C-Left.

Well, for me the current putty (0.67 beta) with its default settings (removed putty's settings from the registry before trying) doesn't, and I find it kind of strange that the terminfo seems to differ that much from what putty actually does. Guess I'll have to join the bug-ncurses mailing list that I've just found and ask there.

[mbunkus]

I'll close this issue again as it's obviously not a problem in tmux.

[l8nite]

This is happening to me too. @mbunkus did you follow up on the mailing list?
Edit: nevermind, found ya - https://lists.gnu.org/archive/html/bug-ncurses/2017-01/msg00002.html

[mbunkus]

I did, though the answer didn't really help me figuring out how to solve this issue (or which application is to blame here). I ended up using the following tmux settings in order to just override the affected keys:

set -g default-terminal screen-256color
set -g terminal-overrides "putty*:kLFT@:kRIT@:kLFT5=\eOD:kRIT5=\eOC:kUP5=\eOA:kDN5=\eOB:smkx@:rmkx@"

Additionally I need to have set -g xterm-keys on active, too, but only if I'm connecting to the tmux session with putty (but not if I'm coming from work where I'm using various Linux systems, not putty). Therefore I don't include that in the global configuration (which I share with many systems). Instead I use a shell script to attach to tmux which also enables or disables xterm-keys based on the current value of $TERM.

[l8nite]

Nice. I switched my TERM variable sent from PuTTy to xterm-256color and it seems to have resolved for me. —

…

You are receiving this because you commented. Reply to this email directly, view it on GitHub <#708 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABodqunzeSyB4P7jxslJujHWSZdh9cuzks5rZfjpgaJpZM4LZ_h4> .

[ThomasDickey]

Actually the terminal description is correct. What's mentioned here is a problem with tmux. If you have a bug report against ncurses, this is not the place to solve it.

[nicm]

I think you're right, we only send smkx when the application inside tmux requests it, but we should be sending it unconditionally and just tweaking what we send inside for the application. I'll take another look at this in a day or so. On 5 Mar 2017 6:09 pm, "ThomasDickey" <notifications@github.com> wrote: Actually the terminal description is correct. What's mentioned here is a problem with tmux. If you have a bug report against ncurses, this is not the place to solve it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#708 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASkcw-zuOBQqkWsq7n7UNVap9RbAnQsks5rivp1gaJpZM4LZ_h4> .

[nicm]

Please try this: x.diff.txt

[mbunkus]

Thank you for looking into this again. I'm currently sick, but I think I can give it a try in a few days.

[nicm]

OK no worries, thanks.

[mbunkus]

I've compiled tmux revision 5d3296c with your patch applied on top of it. Using that tmux binary doesn't really change things for me.

First, clean up and run a new tmux session:

~/opt/tmux/bin/tmux -Ltest kill-server
~/opt/tmux/bin/tmux -vvvv -Ltest -f/dev/null new

Next, I've run cat again and pressed Ctrl+left, up, right, down, in that order. The result:

[0 mosu@sweet-chili ~] cat
^[[1;2D^[[A^[[1;2C^[[B

The result is different from what I've seen with tmux release 2.3. However, starting Emacs inside this tmux via emacs -Q -nw (which is the equivalent of tmux -f/dev/null) and using its describe-key functionality shows that Emacs sees all four key presses as its Ctrl-less counterparts (e.g. it thinks <left> was pressed if I actually press <C-left>.

Here's the tmux-server.log file from that session.

I still have to use the following configuration snippet in order to make Emacs recognize the keys:

set -g terminal-overrides "putty*:kLFT@:kRIT@:kLFT5=\eOD:kRIT5=\eOC:kUP5=\eOA:kDN5=\eOB:smkx@:rmkx@"

I could use Emacs' own configuration to let it recognize ^[[1;2D as <C-left>, but that won't work for Ctrl+up/down as tmux sends the same key sequence as for up/down.

On the other hand… running emacs -Q -nw outside of tmux shows very similar behavior: Emacs sees Ctrl+up/down as up/down.

This is all highly confusing and opaque for me as a lowly user. I do have a working configuration by using the aforementioned terminal-overrides.

[nicm]

Do this please, with the patch applied:

~/opt/tmux/bin/tmux -Ltest kill-server
~/opt/tmux/bin/tmux -vvvv -Ltest -f/dev/null new

Then run "cat" and just press Up then C-Up.

Then C-c and exit tmux and show me the tmux-server*.log file.

^[[1;2D is expected for C-Left - this is the xterm escape sequence. But you should see ^[[1;2A for C-Up.

The idea is we should be able to make it work out of the box without terminal-overrides.

[mbunkus]

Done: tmux-server-22822.log

[nicm]

OK thanks.

I was actually confusing myself - ^[[1;2D is SHIFT Left.

I don't have access to putty so I can just go by what the logs seem to say. In summary:

When we turn smkx on (which we should), it appears that putty sends:

\033OA for Up
\033[A for C-Up (and presumably ALSO S-Up)

terminfo tells us kLFT and kRIT from putty-256color which gives us S-Left and S-Right. But it doesn't have kUP and kDN, I don't know why.

So with my change, you will get S-Left and S-Right sending the xterm S-Left and S-Right inside tmux, S-Up will not send anything different from Up.

If you want tmux to recognise the keys as CTRL, you will need to continue with the terminal-overrides option you are using.

With my patch, you could probably just use this:

set -g terminal-overrides "putty*:kLFT@:kRIT@:kLFT5=\e[D:kRIT5=\e[C:kUP5=\e[A:kDN5=\e[B"

But TBH if what you are using now works, you would be as well just to stick with it.

Anyway I am going to apply my change because we should always be sending smkx so the keys we get from terminfo match up, but it shouldn't make any difference to what you are doing.

[mbunkus]

Thanks for the explanation. Makes sense to me. I'll just stick with my current config, then.

[chros73]

I ended up using the following tmux settings in order to just override the affected keys:

@mbunkus , thanks, you saved me a heartattack :)

[codebymikey]

Solution for me was changing the Default Setting for PuTTY or any of your saved configuration:

• Click Session category, select Default Settings, click Load.
• Click Terminal > Keyboard. Change The Function keys and keypad setting from ESC[n~ to Xterm R6 (or equivalent).
• Click Session category, click Save.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.