端末は、キーボードと出力デバイス (最初はハードコピー プリンター、後に CRT モニター) で構成されるハードウェア デバイスでした。大型のコンピューターには、複数のリモート端末が接続されている場合があります。各端末には、コンピューターと効率的に通信するためのプロトコルがあります。CRT ベースの端末の場合、これには、カーソル位置を変更したり、現在の行/画面の一部を消去したり、別のフルスクリーン モードに切り替えたりするための特別な「制御シーケンス」が含まれます。 ..
端末エミュレーターは、これらの古い端末の 1 つをエミュレートするアプリケーションです。カーソルの配置、前景色と背景色の設定などの機能を実行できます... 端末エミュレーターは特定の端末プロトコルをエミュレートしようとしますが、それぞれに独自の癖と逸脱があります。
Unix システムには端末と端末エミュレータを記述するデータベースがあるため、アプリケーションは使用中の特定の端末 (または端末エミュレータ) から切り離されて抽象化されます。古いデータベースはtermcap(5)、terminfo(5)は新しいデータベースです。これらのデータベースにより、アプリケーションは使用中の端末の機能を照会できます。ケイパビリティは、ブール値、数値ケイパビリティ、さらには文字列ケイパビリティです。たとえば、特定の端末タイプが F12 キーを持っている/サポートしている場合、ケイパビリティ "key_f12" (長期情報名)、"kf12" (短期情報名)、キーが生成する文字列を表す "F2" (termcap 名)。試してみてください: tput kf12 | od -tx1.
機能を直接プログラミングするのは面倒な場合があるため、アプリケーションは通常、curses/ncurses、スラングなどの上位レベルのライブラリを使用します...
と呼ばれる特別な環境変数があり、TERMアプリケーションにどの端末タイプと話しているかを伝えます。最良の結果を得るには、この変数がデータベースに存在する場合は、正確な端末タイプに設定する必要があります。これは、端末が理解する正確なプロトコルとプロトコルの逸脱をアプリケーションに伝えるだけです。TERM変数を変更しても、端末のタイプは変更されません。アプリケーションが通信相手と認識している端末のタイプが変更されるだけです。
つまりCtrl+arrow、terminfo/termcap データベースにはまったく反映されない xterm の動作 (構成オプションに依存) であるため、ほとんどのアプリケーションはそれを認識しません。いずれにせよ、ターミナルエミュレーター（あなたの場合pyte）がそれをサポートしているか、サポートしていないかのどちらかです。
bashあなたの主なアプリケーションが であるか、readlineライブラリを使用する他のアプリケーションであると仮定すると、代わりに readline のbackward-word(デフォルトでは Meta-b/Alt-b/ESC b で構成可能inputrc) を使用することで済むかもしれません。