9

I'm using putty on win7 as client, to log into ssh on a debian server. But I've met a strange problem about keyboard behaviors on putty console.

I noticed that it's about keyboard config in putty. After reading the manual of putty, I successfully made backspace key to work, but still have troubles about ESC, arrows, home and end, and F1-F12 keys.

Here is my keyboard config in putty

Here I list their behaviors below. It seems that the mismapping of ESC is the root cause.

  • ESC => ^[
  • up => ^[OA
  • down => ^[OB
  • right => ^[OC
  • left => ^[OD
  • home => ^[[1~
  • end => ^[[4~
  • F1 => ^[[11~
  • F12 => ^[[24~

================================================

Here I will show why I think esc is mismapping:

When in a correctly working ssh console, I press esc, it should show nothing.

(before)
root@somemachine:
(after)
root@somemachine:

But in this malfunctioning ssh console, I press esc, it shows ^[.

(before)
root@somemachine:
(after)
root@somemachine: ^[

I ran od -c on both ssh console, and pressed esc, they gave the same output.

(normal one)
root@opengg:~# od -c
^[

(malfunctioning one)
$ od -c
^[
2

5 Answers 5

16

The problem is the value of the TERM environment variable does not match the configured terminal characteristics - specifically the "Home and End keys" and "Function keys and keypad" settings.

These can be hard to get right.

What is expected by the Debian server.

Type infocmp -I to see what your computer is expecting.

$ infocmp -I 
#       Reconstructed via infocmp from file: /usr/share/terminfo/a/ansi
ansi|ansi/pc-term compatible with color,
        …
        rmul=\E[m, il1=\E[L, kbs=^H, kcbt=\E[Z, kcud1=\E[B,
        khome=\E[H, kich1=\E[L, kcub1=\E[D, kcuf1=\E[C, kcuu1=\E[A,
        …

khome=\E[H means that the server expects to receive three characters ESC [ H when you press Home.

You can look at what is expected for other values of TERM

$ infocmp -I xterm
#       Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
xterm|X11 terminal emulator,
        …
        is2=\E[!p\E[?3;4l\E[4l\E>, il1=\E[L, ka1=\EOw, ka3=\EOu,
        kb2=\EOy, kbs=\177, kbeg=\EOE, kc1=\EOq, kc3=\EOs,
        kdch1=\E[3~, kcud1=\EOB, kend=\E[4~, kent=\EOM, kf1=\EOP,
        kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
        kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
        kf18=\E[32~, kf19=\E[33~, kf2=\EOQ, kf20=\E[34~, kf3=\EOR,
        kf4=\EOS, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
        kf9=\E[20~, khome=\E[1~, kich1=\E[2~, kcub1=\EOD,
        kmous=\E[M, knp=\E[6~, kpp=\E[5~, kcuf1=\EOC, kcuu1=\EOA,
        …

Here you can see that, if TERM were set to xterm, this server would expect to receive ESC [ 1 ~ when Home is pressed (khome)

If the above is too cryptic, try infocmp -L

You can also do things like tput khome | hexdump -C if you know the terminfo capability names for the keys you are interested in.

$ tput khome | hexdump -C
00000000  1b 5b 48                                          |.[H|

or, arguably more legibly

$ tput khome | hexdump -e '12/1 "%3_u" "\n"'
esc  [  H

or to see what another TERM setting might mean

$ TERM=xterm tput khome | hexdump -e '12/1 "%3_u" "\n"'
esc  [  1  ~

if the output is empty the server thinks that terminal type (TERM) doesn't have that key.

What is actually sent by Putty.

To see what Home actually sends, run vi, press i (for insert mode) press Ctrl+V then press Home and press Esc to exit insert mode.

Solution

Adjust Putty config (or TERM) until what is sent matches what the other end expected.


E.g.

Do as specified in https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/terminfo.html then in Putty, Configuration, Connection, Data, terminal-type string = PuTTY and save that. Maybe.

5
  • Making sense, but the problem is I can't even get ESC to work, let alone home. Seems like I have to solve ESC first, right?
    – OpenGG
    Oct 4, 2011 at 14:59
  • If the ESC key produces ^[ as output, it works as designed.
    – ktf
    Oct 4, 2011 at 15:03
  • @Rufus: ktf is right. Your problem is not the Esc key since the other key definitions in no way depend on how the Esc key is defined. ^[ is short for Ctrl+[, Just as ^A is short for Ctrl+A. [ is the 27th "letter" and Esc is the 27th control code (see ASCII table) Oct 4, 2011 at 15:23
  • For things as standard as Debian and PuTTy, isn't there an off-the-shelf recipe like "upload this config to Debian and this to PuTTy and have the best possible experience ever"?
    – hypersw
    Feb 5, 2018 at 18:25
  • @hypersw chiark.greenend.org.uk/~sgtatham/putty/wishlist/terminfo.html then in Putty, Configuration, Connection, Data, terminal-type string = PuTTY and save that. Maybe. Feb 5, 2018 at 18:39
2

There is no mismapping of the ESC key - ^[ means Control-LeftSquareBracket which is ASCII 27 which is ESC

If you suspect the keys to give wrong sequences, check them with od -c and compare them to the infocmp output:

 $ od -c
 (hit F1 Ctrl-D Ctrl-D)

Output may be (033 is ESC):

 0000000 033   [   1   1   ~

Compare it to the output of infocmp (here \E means ESC):

 $ infocmp -1 | grep 'kf1='
    kf1=\E[11~,

Short introduction to infocmp output:

kbs = Backspace

kcub1, kcud1, kcuf1, kcuu1 = Cursor Keys

kf* = Function keys

kpp / knp = Page up/down

khome / kend = Home / End keys

kich1 / kdch1 = Insert / Delete keys

Using these Informations it should be easy to configure your putty for your system correctly.

1

In my experience it's because bash is not running, simply run /bin/bash to enjoy colors, history and more. And those glitches disappear moreover, making the keyboard working as expected.

You may have to run this command every time you connect or change user, but it's not hard to remember.

0

Until you find a full solution try using vi-style keys instead of the arrows.
H => left
J => down
etc.

0

Certainly there is a "recipe", but PuTTY's developers chose to not participate in the process. The recipe is referred to as a terminal description. There's been a suitable one in ncurses since 2001 (see link for example to terminal database).

The terminal description is specified to most applications as the TERM environment variable.

Rather than use that "recipe", PuTTY by default sets TERM to xterm, which as you have noticed, does not match the special keys (function, cursor). That's mentioned in the ncurses FAQ Why not just use TERM set to "xterm"?

PuTTY is also mentioned (because of the issue with TERM) in the xterm FAQ, although there is no section devoted to it, because it is not actually an "xterm".

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .