Hello.

I guess this problem should be quite well-known, and I was quite surprised that I didn't find a clear description. Anyway, it does not seem to be here, so here is my question.

Putty (an ssh client for windows) identifies its terminal emulator as "xterm" by default, but the character sequences I get for some keys are not the same as I get in a descent xterm (I've tried twice, on two different machines with two different linux distros). Namely, in putty, shift+up, ctrl+up, and alt+up produce ^[OA, ^[OA, and ^[^[[A, respectively, while in the real xterm they produce ^[[1;2A, ^[[1;5A, and ^[[1;3A, resp. All the same for other arrow keys. Note that the codes for shift+up and ctrl+up produce the same character sequences, so a program running on the server-side will be completely unable to distinguish between them, whatever configuration I set up on the server-side.

Maybe, I don't know something important (e. g. there is a general and official linux standard called "xterm" and a program also called "xterm", and the program violates the standard, while putty does not), but for me this looks like a bug in putty (if you call yourself "xterm", you should behave like xterm), and I have the intent to report it to putty developers. But first I would like to ask: maybe I really miss something important? It is very strange for me that such a situation (which should have occurred a lot of times to a lot of users) has not been yet reported (I searched through putty bug reports).

PS The same situation is for Fn keys, but for the Fn keys I know how to reconfigure putty so that it sends the same sequences as xterm (even though this is not the deault putty configuration).

PPS I know that there is some terminal setting, which is controlled from inside the terminal (by "printing" a special sequence of characters) and which is called "application mode". I believe that it is related with ncurses, but AFAIK it can also be toggled by hand, by the commands
to turn it on and
to turn it off. Doing this changes the behavior of shift+arrow, etc keys in putty (in the real xterm they stay the same!), but they don't become like in xterm anyway: shift+up, ctrl+up, and alt+up then produce ^[[A, ^[[A, and ^[^[OA, resp.

I'm looking at the source code for putty right now. It seems the escape sequences for the arrow keys are hard coded into it. It's in terminal.c, around line 6015, int format_arrow_key(char *buf, Terminal *term, int xkey, int ctrl). Control is the only modifier it seems to care about.

Any way you cut it, the codes for arrows/home/end/ins/del/pgup/pgdn/Fn are hard to predict. They are supposed to be the ones in terminfo, but there is no guarantee that the terminal emulator you use actually abides by this. For example, rxvt actually makes up it's own sequences for any of these keys with control/shift modifiers, and doesn't even look at terminfo. It's not surprising that putty does this also.

I have so many hacks to determine the state of the modifiers from a terminal window I can't even tell you. There's a different set for every different terminal: linux/xterm/rxvt/etc. It's a gong show.

1. I looked through terminfo manual a little, but I didn't find how it can prescribe the sequence for ctrl+arrow. Anyway, this is not the problem. rxvt does produce different sequences for ctrl+arrow than xterm does, but rxvt doesn't call itself xterm in the TERM variable. So, the programs working inside rxvt don't try to interpret the codes given by rxvt as if they were given by xterm. Konsole and gnome-terminal do call themselves xterm, but they produce the same codes. Putty also tells internal programs that it is xterm, but it produces wrong codes. And yes, despite I didn't find how ctrl+arrow keys are represented in terminfo, but, for example, I did find how fn keys are represented. In the cases of rxvt, xterm, konsole, and gnome-terminal, the sequences actually produced by the terminal coincide with what terminfo for the vaule of TERM variable (rxvt or xterm) says they should be. In case of putty, they don't coincide.

2. If I am going to report a bug, not to write an ncurses program which will work with the current (apparently buggy) behavior of putty (an will not work in xterm, konsole and gnome-terminal then, I can't distinguish them from inside the terminal). An for a bug report, it should not be a problem that the wrong sequences are now hardcoded. And my question in this thread was not "how to fix it" (while this information is also helpful, thank you), but rather "why did this behavior appeared at all"? Why did putty developers decide that putty will set TERM=xterm and deliberately hardcoded the sequences for ctrl+arrows, which were different than what actual xterm produces? This does not look like a usual mistake, so I conclude that I don't understand something and the things are not as wrong as they look for me.