☰

ssh backspace não funciona até que eu execute manualmente TERM=xterm

tag-icon • tag-icon bash ssh
ssh backspace não funciona até que eu execute manualmente TERM=xterm

Entendo que backspace agora pode funcionar em uma sshsessão se TERMestiver definido incorretamente. Mas estranhamente, tenho um servidor onde TERMestá configurado corretamente, mas backspace não funciona até que eu configure manualmente TERM=xtermno shell (o que deve ser redundante). Veja aqui:

~ ] ssh [email protected]
root 192.168.10.40 / # echo $0
-bash
root 192.168.10.40 / # echo $TERM
xterm-256color
root 192.168.10.40 / #     # backspace does not work :(
root 192.168.10.40 / # 
root 192.168.10.40 / # TERM=xterm-256color
root 192.168.10.40 / # # now backspace works!!
root 192.168.10.40 / # logout

Eu diria que cerca de 90% das vezes, backspace não funciona até que eu execute TERM=xterme 10% das vezes, não preciso executar o TERM=comando porque backspace já está funcionando. Comparei a saída de envcada caso e eles são idênticos (exceto SSH_CLIENTe SSH_CONNECTIONonde apenas a porta do lado do cliente foi alterada)

Alguma ideia do que pode causar esse comportamento ou qual pode ser uma solução alternativa?

Resposta aos comentários

Estou usando OpenSSH_6.8p1, BoringSSLfrom https://android.googlesource.com/platform/external/opensshe estou fugindo GNU bash, version 4.3.42(1)-release (arm-android-eabi)dehttps://github.com/CyanogenMod/android_external_bash.git

stty -anão mostra diferença antes e depois da configuração XTERM. A saída é:

speed 38400 baud; rows 102; columns 319; line = 2;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

bind -p|egrep 'delete|rubout|kill'também não mostra diferença antes e depois da configuração XTERM. A saída é:

"\C-h": backward-delete-char
"\C-?": backward-delete-char
"\C-x\C-?": backward-kill-line
"\e\C-h": backward-kill-word
"\e\C-?": backward-kill-word
# copy-region-as-kill (not bound)
"\C-d": delete-char
"\e[3~": delete-char
# delete-char-or-list (not bound)
"\e\\": delete-horizontal-space
# forward-backward-delete-char (not bound)
"\C-k": kill-line
# kill-region (not bound)
# kill-whole-line (not bound)
"\ed": kill-word
# shell-backward-kill-word (not bound)
# shell-kill-word (not bound)
# unix-filename-rubout (not bound)
"\C-w": unix-word-rubout
# vi-delete (not bound)
# vi-delete-to (not bound)
# vi-overstrike-delete (not bound)
# vi-rubout (not bound)

Curiosamente, se eu sourceusar meu backspace bashrc, meu backspace começará a funcionar novamente. Eu sei que bashrcestá sendo obtido no login porque esse é o único lugar onde defino meu Ps1valor

Responder1

Parece uma interação readline/terminal, comece verificando sua variável de ambiente .inputrc, /etc/inputrc, /etc/default/login, INPUTRCdurante o processo de login e, em seguida, as ligações readline (via bind -q backward-delete-char).

Não há problema em verificar novamente o que está nas diretivas cliente (ssh_config) SendEnve servidor (sshd_config ) também, se houver (embora não seja enviado do cliente para o servidor desta forma no OpenSSH, o cliente sempre inclui o valor na configuração da sessão e no conjunto do servidor a partir desse). A presença ocasional ou no ambiente é a única coisa que consigo pensar para explicar a natureza intermitente disso.AcceptEnvTERMTERMTERMTERMINFOTERMCAP

Readline aplica "rubout" a tudo o que o terminal declara ser "apagar", e rubout é o que readline invoca via backward-delete-char.

TERMé uma das variáveis ​​especiais que o bash monitora, quando está definida (independentemente de sermudanças)bash redefine o terminal:

/* What to do just after one of the TERMxxx variables has changed.
   If we are an interactive shell, then try to reset the terminal
   information in readline. */
void
sv_terminal (name)
     char *name;
{
  if (interactive_shell && no_line_editing == 0)
    rl_reset_terminal (get_string_value ("TERM"));
}

(onde " TERMxxx" significa e ) TERM, então isso explica por que simplesmente definir seu valor atual realmente executa uma ação.TERMCAPTERMINFOTERM

Se você não conseguir rastreá-lo, adicionar " TERM=${TERM}" no final do seu .profile/ .bashrcpode ser uma solução alternativa.

Como último recurso, você também pode tentar algumas medidas forenses, conforme detalhado na minha resposta aqui:Monitorar e alertar o usuário quando as configurações stty forem alteradas?

informação relacionada