web-dev-qa-db-ja.com

長い入力文字列でbash（ttyおよびX）で奇妙に動作するホームキー

ヒットしたとき Home 現在の入力が十分に短い場合（たとえば、36文字未満）、正常に機能します。ただし、長いコマンドを入力して最初に戻りたい場合は、そのコマンドは機能しているように見えますが、コマンドは表示正しくありません。私は最初ではないように見えますが、約10文字ずれています。 「ブラインド」と入力すると問題なく動作しますが、入力全体が右にシフトされているように見えますが、再描画されていないように見えます。だから私はそれをタイプしますが、私が「消去」している場所は「実際には」右に10文字あるので、「実際には」そうではありません。したがって、コマンドを消去しようとすると、最初の10文字は表示されたままですが、 Enter 前の入力が空であるかのように、別のプロンプトを表示するだけです。

これまでで最高の説明ではないことはわかっていますが、要点は、bashがそれを認識して正しいことをしようとしますが、失敗することが多いということです。

私はこれをttyとXセッションの端末の両方で再現します。ヒットしたとき Ctrl+V その後 Home 異なるシーケンス（Xでは^[OH、ttyでは^[[1~）が表示されますが、どちらも私の/etc/inputrcにあるようです。

# do not bell on tab-completion
#set bell-style none

set meta-flag on
set input-meta on
set convert-meta off
set output-meta on

$if mode=emacs

# for linux console and RH/Debian xterm
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[7~": beginning-of-line
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-Word
"\e[5D": backward-Word
"\e\e[C": forward-Word
"\e\e[D": backward-Word
"\e[1;5C": forward-Word
"\e[1;5D": backward-Word

# for rxvt
"\e[8~": end-of-line

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line

# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line
$endif

echo $TERMは、ttyではlinuxを示し、Xセッションではxtermを示します。

それは

GNU bash、バージョン4.2.24（2）-リリース（i686-pc-linux-gnu）

誰かがこれについて手がかりを持っていますか？

bashcommand-linearch-linux
11
Lev Levitsky

プロンプトの印刷されない部分（色を変更するためのエスケープシーケンスを含むがこれに限定されない）を\[および\]で囲む必要があります。

元のプロンプト：\e[0;36m[\u@\h \W]\$ \e[m
修正されたプロンプト：\[\e[0;36m\][\u@\h \W]\$ \[\e[m\]

\[と\]は、bashに、その間のすべてが実際には画面に出力されない、つまり長さがゼロであることを通知します。入力した文字をエコーする場所を知るには、計算されたプロンプトの長さが必要です。 \[ \]を省略すると、bashが誤ったプロンプトの長さを計算します。これは、カーソルが現実と一致していない場所に関するbashの考えにより、端末のジオメトリに依存する奇妙な動作につながることがよくあります。 。

13
jw013