Entendo que backspace agora pode funcionar em uma ssh
sessão se TERM
estiver definido incorretamente. Mas estranhamente, tenho um servidor onde TERM
está configurado corretamente, mas backspace não funciona até que eu configure manualmente TERM=xterm
no 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=xterm
e 10% das vezes, não preciso executar o TERM=
comando porque backspace já está funcionando. Comparei a saída de env
cada caso e eles são idênticos (exceto SSH_CLIENT
e SSH_CONNECTION
onde 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, BoringSSL
from https://android.googlesource.com/platform/external/openssh
e estou fugindo GNU bash, version 4.3.42(1)-release (arm-android-eabi)
dehttps://github.com/CyanogenMod/android_external_bash.git
stty -a
nã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 source
usar meu backspace bashrc
, meu backspace começará a funcionar novamente. Eu sei que bashrc
está sendo obtido no login porque esse é o único lugar onde defino meu Ps1
valor
Responder1
Parece uma interação readline/terminal, comece verificando sua variável de ambiente .inputrc
, /etc/inputrc
, /etc/default/login
, INPUTRC
durante 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) SendEnv
e 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.AcceptEnv
TERM
TERM
TERM
TERMINFO
TERMCAP
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.TERMCAP
TERMINFO
TERM
Se você não conseguir rastreá-lo, adicionar " TERM=${TERM}
" no final do seu .profile
/ .bashrc
pode 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?