putty が Windows 上で実行されている ssh サーバーに接続され、cmd.exe がシェルとして使用されている場合、カーソル キーは正しく機能しません。通常は、古いコマンドを呼び出すことができますが、cursor up/downputty 内ではこれは機能しません。
putty のターミナル タイプを変更してもうまくいきませんでした。別のシェルを使用しても解決にはなりません。putty でそれができない場合は、キー バインディング/ターミナル エミュレーションを変更できる別の ssh クライアントがあるでしょうか?
答え1
問題はクライアントではなくサーバーにある可能性が高いです。
PuTTY は、Xterm/VT100 端末エミュレータです。VT100 端末は、単純な 8 ビット シリアル ストリームの一方の端に接続され、ファンクション キー (たとえば矢印) 用の特別な「エスケープ シーケンス」を送信します。ESC [ AこれUpは、今日の Linux や BSD でも引き続き使用されています。基本的な行編集を超える行編集は← Backspace、プログラム自体によって処理され、これらのエスケープ シーケンスを読み取って解析し、カーソルを移動してテキストを表示するためにさらにエスケープ シーケンスを出力します。Telnet と SSH はどちらも、シリアル ラインとまったく同じように、端末ストリームの単純なキャリアと考えることができます。
問題の原因は、Windowsコンソールがないそのように動作します。コンソールはストリームではなく、画面バッファです。コンソールサブシステムには行編集（および基本的な履歴）が組み込まれており、コマンドプロンプトこの機能を単にコンソールの読み取り()– 矢印キーイベントは、明示的に「ライン入力」モードを無効にしない限り、プログラムには届きません。(Windows APIには、出力スタイル用の別の関数もあります。)コマンドプロンプトの入力がコンソールではなくパイプに接続されている場合、このシステムはバイパスされ、すべてが入力ストリームに直接挿入されます。コマンドプロンプトVT100 シーケンスを処理するために書かれたものではないため、特別な処理は行われず、ESC単に入力されたコマンドの一部になります。
これは、Windows SSHサーバーとWindows組み込みTelnetサーバーが、VT100シーケンスをコンソールイベントに変換し、フォーマットされたコンソール出力をVT100シーケンスに変換する必要があることを意味します。すべてのSSHサーバーが実際にそれを行うわけではありません。リモートエンドが使用するSSHサーバーソフトウェアを変更していないことを確認してください。キーが働いていたとともに同じputty -cleanup設定が現在と同じでない場合は、レジストリ ブランチを手動で削除して、PuTTY をデフォルト設定にリセットしてみてください。
Windows PowerShellにはリモートサポートは、ローカルの行編集を使用し、リモートエンドに完全な行のみを送信するため、この問題を回避できます。コマンドプロンプトこれは次のように達成できる。psexec（SMB接続はデフォルトでは暗号化されませんが）、またはおそらく始められるだろうコマンドPowerShell リモート セッション内から。