TERM = xtermを手動で実行するまで、SSHバックスペースキーは機能しません。

TERM = xtermを手動で実行するまで、SSHバックスペースキーは機能しません。

私が知っている限り、バックスペースキーが正しく設定されていないssh場合はTERM、セッション内で動作できます。しかし、奇妙なことに、サーバーは正しく設定されていますが、シェルで手動で設定するTERMまでバックスペースキーは機能しません(重複する必要があります)。TERM=xtermねえ:

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

バックスペースキーを実行するまでバックスペースキーが機能しない場合は約90%、バックスペースキーはすでに機能しているため、コマンドをTERM=xterm実行する必要がない場合は10%です。各ケースの出力をTERM=比較しましたがenv、同じです(クライアントポートのみが変更されたSSH_CLIENTことを除き)。SSH_CONNECTION

この動作の原因が何であるか、解決策が何であるかをご存知ですか?


コメントへの返信

私はOpenSSH_6.8p1, BoringSSLfromを使用していてfromをhttps://android.googlesource.com/platform/external/openssh使用しています。GNU bash, version 4.3.42(1)-release (arm-android-eabi)https://github.com/CyanogenMod/android_external_bash.git

stty -aディスプレイ設定の前後に違いはありませんXTERM。出力は次のとおりです

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'また、設定前と設定後の差がないことを示しますXTERM。出力は次のとおりです

"\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)

興味深いことに、を押すとsourceバックbashrc​​スペースキーが再び機能し始めます。値を設定したbashrc唯一の場所なので、ログイン時に情報を取得することを知っています。Ps1

答え1

readline/terminal 相互作用のように見えます。まずログイン中に.inputrc、、、、環境変数を確認してからreadlineがバインドされます(passes /etc/inputrc)。/etc/default/loginINPUTRCbind -q backward-delete-char

また、クライアント(ssh_config)SendEnvおよびサーバー(sshd_config AcceptEnv)ディレクティブに何があるかを再確認することも悪くありません(TERMOpenSSHではこの方法でクライアントからサーバーに送信されませんが、クライアントは常にTERMセッション設定値に含まれます)。 、サーバーはTERMこれに設定されます)。これが断続的に発生すると説明できる唯一の理由は、TERMINFO環境に時々存在するためです。TERMCAP

Readlineは、端末が「削除」と宣言したすべてに「rubout」を適用し、ruboutはを通じてreadlineが呼び出されることですbackward-delete-char

TERMbashが設定されたときに監視する特別な変数の1つです。多様性)バッシュリセット端末:

/* 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"));
}

(ここで、 " TERMxxx"はTERMTERMCAPおよびを意味しますTERMINFO。)したがって、TERM現在の値に設定するだけで実際に操作が実行される理由が説明されます。

見つからない場合は、TERM=${TERM}/末尾に ""を追加することが回避策かもしれません。.profile.bashrc

最後の手段として、私の答えに記載されているように、いくつかの法医学的措置を試すこともできます。stty設定が変更された場合は、ユーザーに監視して警告しますか?

関連情報