web-dev-qa-db-ja.com

パテでキーボードが正しく機能しない

Win7のPuTTYをクライアントとして使用して、debianサーバーのsshにログインしています。しかし、PuTTYコンソールでのキーボードの動作に関する奇妙な問題に遭遇しました。

私はそれがPuTTYのキーボード設定に関するものであることに気づきました。 PuTTYのマニュアル を読んだ後、backspaceキーを正常に機能させることができましたが、ESC、arrows、homeとend、およびF1-F12キーについてはまだ問題があります。

Here is my keyboard config in PuTTY

ここに私は彼らの行動を以下にリストします。 ESCの誤ったマッピングが根本的な原因のようです。

  • ESC => ^ [
  • up => ^ [OA
  • down => ^ [OB
  • right => ^ [OC
  • left => ^ [OD
  • home => ^ [[1〜
  • end => ^ [[4〜
  • F1 => ^ [[11〜
  • F12 => ^ [[24〜

================================================

ここで、escが誤ってマッピングされていると思う理由を示します。

正常に動作しているsshコンソールでescを押すと、何も表示されないはずです。

(before)
root@somemachine:
(after)
root@somemachine:

しかし、この誤動作しているsshコンソールで、escを押すと、^[と表示されます。

(before)
root@somemachine:
(after)
root@somemachine: ^[

両方のsshコンソールでod -cを実行し、escを押したところ、同じ出力が得られました。

(normal one)
root@opengg:~# od -c
^[

(malfunctioning one)
$ od -c
^[
sshkeyboardputty
7
Rufus

問題は、TERM環境変数の値が、構成された端末の特性、特に「HomeキーとEndキー」および「ファンクションキーとキーパッド」の設定と一致しないことです。

これらは正しく理解するのが難しい場合があります。

Debianサーバーが期待すること。

infocmp -Iと入力して、コンピューターが予期していることを確認します。

$ infocmp -I 
#       Reconstructed via infocmp from file: /usr/share/terminfo/a/ansi
ansi|ansi/pc-term compatible with color,
        …
        rmul=\E[m, il1=\E[L, kbs=^H, kcbt=\E[Z, kcud1=\E[B,
        khome=\E[H, kich1=\E[L, kcub1=\E[D, kcuf1=\E[C, kcuu1=\E[A,
        …

khome=\E[Hは、サーバーがを押したときに3文字ESC [ Hを受け取ることを期待していることを意味します Home。

TERMの他の値に期待されるものを見ることができます

$ infocmp -I xterm
#       Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
xterm|X11 terminal emulator,
        …
        is2=\E[!p\E[?3;4l\E[4l\E>, il1=\E[L, ka1=\EOw, ka3=\EOu,
        kb2=\EOy, kbs=\177, kbeg=\EOE, kc1=\EOq, kc3=\EOs,
        kdch1=\E[3~, kcud1=\EOB, kend=\E[4~, kent=\EOM, kf1=\EOP,
        kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
        kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
        kf18=\E[32~, kf19=\E[33~, kf2=\EOQ, kf20=\E[34~, kf3=\EOR,
        kf4=\EOS, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
        kf9=\E[20~, khome=\E[1~, kich1=\E[2~, kcub1=\EOD,
        kmous=\E[M, knp=\E[6~, kpp=\E[5~, kcuf1=\EOC, kcuu1=\EOA,
        …

ここで、TERMがxtermに設定されている場合、このサーバーはESC [ 1 ~を受け取ることを期待していることがわかります。 Home 押された（khome）

上記が難解すぎる場合は、infocmp -Lをお試しください

興味のあるキーのterminfo機能名がわかっている場合は、tput khome | hexdump -Cのようなこともできます。

$ tput khome | hexdump -C
00000000  1b 5b 48                                          |.[H|

または、おそらくより読みやすい

$ tput khome | hexdump -e '12/1 "%3_u" "\n"'
esc  [  H

または、別のTERM設定の意味を確認する

$ TERM=xterm tput khome | hexdump -e '12/1 "%3_u" "\n"'
esc  [  1  ~

出力が空の場合、サーバーは端末タイプ（TERM）にそのキーがないと見なします。

PuTTYによって実際に送信されるもの。

何を見るために Home 実際に送信してviを実行し、押す i （挿入モードの場合）を押します Ctrl+V 次に押す Home そして押す Esc 挿入モードを終了します。

解決

送信されるものが相手側の期待と一致するまで、PuTTY構成（またはTERM）を調整します。

例えば。

https://www.chiark.greenend.org.uk/~sgtatham/PuTTY/wishlist/terminfo.html で指定されているようにしてから、PuTTY、設定、接続、データ、端末タイプ文字列= PuTTYを保存します。多分。

14
RedGrittyBrick

[〜＃〜] esc [〜＃〜]キーの誤マッピングはありません-^ [は、ASCII 27であるControl-LeftSquareBracketを意味します。これはESCです

キーが間違ったシーケンスを与えると思われる場合は、それらをod -cで確認し、それらをinfocmp出力と比較します。

 $ od -c
 (hit F1 Ctrl-D Ctrl-D)

出力は（033は[〜＃〜] esc [〜＃〜]）：

 0000000 033   [   1   1   ~

それをinfocmpの出力と比較します（ここで\Eは[〜＃〜] esc [〜＃〜]）を意味します：

 $ infocmp -1 | grep 'kf1='
    kf1=\E[11~,

Infocmp出力の簡単な紹介：

kbs =バックスペース

kcub1、kcud1、kcuf1、kcuu1 =カーソルキー

kf * =ファンクションキー

kpp/knp =ページアップ/ダウン

khome/kend =ホーム/終了キー

kich1/kdch1 =キーの挿入/削除

これらの情報を使用すると、システムのPuTTYを簡単に正しく設定できます。

2
ktf

私の経験では、bashが実行されていないためです。単に/ bin/bashを実行して、色や履歴などを楽しんでください。さらに、これらの不具合は解消され、キーボードは期待どおりに機能します。

ユーザーを接続または変更するたびにこのコマンドを実行する必要があるかもしれませんが、覚えておくのは難しくありません。

1
JoelBonetR

完全な解決策が見つかるまで、矢印の代わりにviスタイルのキーを使用してみてください。
H =>左
J =>ダウン
等。

0
Yitzchak

確かに「レシピ」はありますが、PuTTYの開発者はプロセスに参加しないことを選択しました。レシピは端末記述と呼ばれます。 2001 以降、ncursesに適切なものがありました（たとえば、 端末データベース へのリンクを参照してください）。

端末の説明は、ほとんどのアプリケーションでTERM環境変数として指定されています。

その「レシピ」を使用するのではなく、PuTTYはデフォルトでTERMをxtermに設定します。特殊キー（ファンクション、カーソル）と一致しません。 ncursesに記載されていますFAQ TERMを "xterm"に設定して使用しないのはなぜですか？

xterm FAQ ）でPuTTYについても言及しています（TERMの問題のため）。 「xterm」。

0
Thomas Dickey