☰

ssh backspace no funciona hasta que ejecuto manualmente TERM=xterm

tag-icon • tag-icon bash ssh
ssh backspace no funciona hasta que ejecuto manualmente TERM=xterm

Entiendo que la tecla de retroceso podría funcionar ahora en una sshsesión si TERMse configura incorrectamente. Pero, extrañamente, tengo un servidor que TERMestá configurado correctamente, pero la tecla de retroceso no funciona hasta que lo configuro manualmente TERM=xtermen el Shell (lo cual debería ser redundante). Mira aquí:

~ ] 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

Yo diría que aproximadamente el 90% de las veces, la tecla de retroceso no funciona hasta que ejecuto TERM=xterm, y el 10% de las veces, no necesito ejecutar el TERM=comando porque la tecla de retroceso ya está funcionando. He comparado el resultado de envcada caso y son idénticos (aparte de SSH_CLIENTdonde SSH_CONNECTIONsolo ha cambiado el puerto del lado del cliente)

¿Alguna idea de qué puede causar este comportamiento o cuál podría ser una solución alternativa?

Respuesta a comentarios

Estoy usando OpenSSH_6.8p1, BoringSSLfrom https://android.googlesource.com/platform/external/opensshy estoy huyendo GNU bash, version 4.3.42(1)-release (arm-android-eabi)dehttps://github.com/CyanogenMod/android_external_bash.git

stty -aNo muestra diferencias antes y después del ajuste XTERM. La salida es:

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'Tampoco muestra diferencias antes y después de la configuración XTERM. La salida es:

"\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, si hago sourceclic bashrc, mi retroceso comienza a funcionar nuevamente. Sin embargo, sé que bashrcse obtiene al iniciar sesión porque ese es el único lugar donde establezco mi Ps1valor.

Respuesta1

Parece una interacción readline/terminal, comience verificando su .inputrcvariable /etc/inputrcde /etc/default/loginentorno INPUTRCdurante el proceso de inicio de sesión y luego lea los enlaces de línea (a través de bind -q backward-delete-char).

No hay nada de malo en verificar lo que hay en las directivas del cliente (ssh_config) SendEnvy del servidor (sshd_config AcceptEnv), en todo caso (aunque TERMno se envía del cliente al servidor de esta manera en OpenSSH, el cliente siempre incluye el TERMvalor en la configuración de la sesión y el conjunto del servidor). TERMa partir de ese). La presencia ocasional de TERMINFOo TERMCAPen el medio ambiente es lo único que se me ocurre para explicar la naturaleza intermitente de esto.

Readline aplica "rubout" a lo que el terminal declara que es su "borrado", y rubout es lo que readline invoca a través de backward-delete-char.

TERMes una de las variables especiales que bash monitorea, cuando está configurada (independientemente de sicambios)bash reinicia el 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"));
}

(donde " TERMxxx" significa TERMy ) TERMCAP, TERMINFOesto explica por qué simplemente establecer TERMsu valor actual en realidad realiza una acción.

Si no puede localizarlo, agregar " TERM=${TERM}" al final de su .profile/ .bashrcpodría ser una solución alternativa.

Como último recurso, también puedes probar algunas medidas forenses, como se detalla en mi respuesta aquí:¿Supervisar y alertar al usuario cuando cambian las configuraciones de stty?

información relacionada