Não é possível fazer o teclado funcionar corretamente no putty

Question

Estou usando o putty no win7 como cliente, para efetuar login no ssh em um servidor Debian. Mas eu encontrei um problema estranho sobre os comportamentos do teclado no console de massa.

Eu notei que é sobre a configuração do teclado no putty. Depois de ler o manual de massa , consegui backspace chave para trabalhar, mas ainda tem problemas sobre ESC , setas, home e end e F1 - F12 chaves.

Aqui eu listo seus comportamentos abaixo. Parece que o mapeamento incorreto de ESC é a causa raiz.

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

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

Aqui mostrarei porque acho que esc é um mapeamento incorreto:

Quando em um console ssh funcionando corretamente, eu pressiono esc , ele não deve mostrar nada.

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

Mas neste console ssh com problemas, eu pressiono esc , ele mostra ^[ .

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

Eu corri od -c no console do ssh, e pressionei esc , eles deram o mesmo resultado.

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

(malfunctioning one)
$ od -c
^[

    

Answer 1

O problema é que o valor da variável de ambiente TERM não corresponde às características do terminal configurado - especificamente as configurações "Home and End keys" e "Function keys and keypad".

Isso pode ser difícil de acertar.

O que é esperado pelo servidor Debian.

Digite infocmp -I para ver o que seu computador está esperando.

$ 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 significa que o servidor espera receber três caracteres ESC [ H quando você pressiona Início .

Você pode ver o que é esperado para outros valores de 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=7, 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,
        …

Aqui você pode ver que, se TERM fosse definido como xterm , este servidor esperaria receber ESC [ 1 ~ quando Início for pressionado ( khome )

Se o acima for muito enigmático, tente infocmp -L

Você também pode fazer coisas como tput khome | hexdump -C se souber os nomes dos recursos terminfo para as teclas de seu interesse.

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

ou, sem dúvida, de forma mais legível

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

ou para ver o que outra configuração TERM pode significar

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

se a saída estiver vazia, o servidor pensa que o tipo de terminal (TERM) não tem essa chave.

O que é realmente enviado por Putty.

Para ver o que Home realmente envia, execute vi , pressione i (para o modo de inserção) pressione Ctrl + V pressione Home e pressione Esc para sair do modo de inserção.

Solução

Ajuste o Putty config (ou TERM) até que o que é enviado corresponda ao que o outro lado espera.

Por exemplo,

Faça conforme especificado no link , em seguida, em Putty, Configuração, Conexão , Dados, tipo de terminal string = PuTTY e salve isso. Talvez.

    

Answer 2

Não há erro de mapeamento da chave ESC - ^ [significa Control-LeftSquareBracket, que é ASCII 27, que é ESC

Se você suspeitar que as chaves deram sequências erradas, verifique-as com od -c e compare-as com a saída infocmp :

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

A saída pode ser ( 033 é ESC ):

 0000000 033   [   1   1   ~

Compare com a saída de infocmp (aqui \E significa ESC ):

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

Breve introdução à saída infocmp:

kbs = retrocesso

kcub1 , kcud1 , kcuf1 , kcuu1 = Teclas do cursor

kf * = Teclas de função

kpp / knp = Página para cima / para baixo

khome / kend = teclas de início / fim

kich1 / kdch1 = Inserir / excluir chaves

Usando estas informações, deve ser fácil configurar o massa para o seu sistema corretamente.

    

Answer 3

Na minha experiência, é porque o bash não está rodando, simplesmente rode / bin / bash para curtir cores, história e muito mais. E essas falhas desaparecem, fazendo o teclado funcionar como esperado.

Você pode ter que executar este comando toda vez que se conectar ou mudar de usuário, mas não é difícil lembrar.

    

Answer 4

Até encontrar uma solução completa, tente usar chaves no estilo vi em vez das setas.
H = > esquerda
J = > para baixo
etc.

    

Answer 5

Certamente existe uma "receita", mas os desenvolvedores do PuTTY preferiram não participar do processo. A receita é referida como uma descrição do terminal . Tem havido um adequado em ncurses desde 2001 (ver link por exemplo para banco de dados do terminal ).

A descrição do terminal é especificada para a maioria das aplicações como a variável de ambiente TERM .

Em vez de usar essa "receita", o PuTTY, por padrão, define TERM para xterm , o que, como você observou, não corresponde às teclas especiais (função, cursor). Isso é mencionado na ncurses FAQ Por que não usar apenas TERM definido como "xterm"?

O PuTTY também é mencionado (devido ao problema com TERM ) na FAQ do xterm , embora não haja uma seção dedicada a ele, porque na verdade não é um "xterm".