私が知っている限り、バックスペースキーが正しく設定されていない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, BoringSSL
fromを使用していて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/login
INPUTRC
bind -q backward-delete-char
また、クライアント(ssh_config)SendEnv
およびサーバー(sshd_config AcceptEnv
)ディレクティブに何があるかを再確認することも悪くありません(TERM
OpenSSHではこの方法でクライアントからサーバーに送信されませんが、クライアントは常にTERM
セッション設定値に含まれます)。 、サーバーはTERM
これに設定されます)。これが断続的に発生すると説明できる唯一の理由は、TERMINFO
環境に時々存在するためです。TERMCAP
Readlineは、端末が「削除」と宣言したすべてに「rubout」を適用し、ruboutはを通じてreadlineが呼び出されることですbackward-delete-char
。
TERM
bashが設定されたときに監視する特別な変数の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
"はTERM
、TERMCAP
およびを意味しますTERMINFO
。)したがって、TERM
現在の値に設定するだけで実際に操作が実行される理由が説明されます。
見つからない場合は、TERM=${TERM}
/末尾に ""を追加することが回避策かもしれません。.profile
.bashrc
最後の手段として、私の答えに記載されているように、いくつかの法医学的措置を試すこともできます。stty設定が変更された場合は、ユーザーに監視して警告しますか?