ターミナルで誤ってCtrl-Sを押した後にフリーズを解除するにはどうすればよいですか？

これは私にとって非常に頻繁に発生する状況です。Ctrl-S端末で（別の意図で）を押すと、端末との対話（入力または出力）がフリーズします。これはおそらく一種の「スクロールロック」などです。

この後、ターミナルをフリーズ解除するにはどうすればよいですか？

（今回はapt-shell、bash内部で作業していました- urxvtどちらが特別な処理を担当するのかわからないCtrl-S：C-r通常のreadline でコマンド履歴を逆方向に検索していましたが、 「前方いつもと歴史を通して-少なくともEmacs--にC-s（1、2、3。）が、それは、端末がフリーズする原因と過去のものを表示するには、まあ、スクロール/ページングがまだの端末で動作しますが、相互作用なしプロセスがそこで実行されます。）

Ctrl-Q

これを完全に無効にするにstty -ixonは、起動スクリプトを使用します。任意のキーで物事が再び流れるようにするには、を使用しますstty ixany。

ps：これを行うのは端末でもシェルでもありませんが、OSの端末ドライバーです。

Ctrl- Q確かに答えです。私はak2の正解の余白に収まるには長すぎるこの小さな歴史の中で投げることになると思った。

暗黒時代に戻って、ターミナルは、長いワイヤーまたはモデム付き電話回線を介してリモートデバイス（テレタイプは電信キーよりも操作がはるかに簡単だったため、もともとは別のターミナル）に接続する大きな機器でした。Unixが開発された頃には、ASCIIコードはすでに十分に確立されていました（ただし、IBMからの競合するEBCDICコードはまだ考慮すべき力でした）。

最古の端末は、受信したすべてのキャラクターの印刷記録を保持していました。文字が到着する限り、少なくともプリントヘッドが文字を入力するよりも速くはありません。しかし、CRTベースの端末が使用可能になるとすぐに、CRTに収まるのは約25行のみであり、80文字の25行が十分なRAMを表しているため、画面の上部からスクロールした文字にRAMを追加することを真剣に考える人はいませんでしたスクリーン。

そのため、送信側が一時停止してリーダーが追いつくように通知するために、何らかの規則が必要でした。

7ビットASCIIコードには、制御文字専用の33個のコードポイントがあります（0〜31および127）。それらのいくつかは、以下のような本当によく設立目的、持っていたNUL、（白紙テープスレッディング、ギャップ、およびスプライスのためのリーダー）DEL（全7つの穴を打ち抜いて示された紙テープ上の文字「消さ」）、 BEL（鼎！）、 、CR、LFとしTAB。が、4は（端末装置自体を制御するために明示的に定義されたDC1にDC4別名はCtrl + Qは、Ctrl + R、Ctrlキー+ SとCtrl + T）。

私の最良の推測は、一部のエンジニアが（ニーモニックのとおり）、「停止」の「S」および「継続」の「Q」はそれほど悪くないDC3とDC1考え、「送信を停止してください」および「OK」 、今すぐ送信を続けてください」。

その慣習でさえ、UnixがBell Labsに巣立って世界に出て行く頃にはすでに確立されていました。

この規則はソフトウェアフロー制御として知られており、実際のシリアルデバイスでは非常に一般的です。正しく実装するのは容易ではありません。通信チャネルで他の目的にこれらの文字を使用することができず、保留中の受信文字よりも先にStop信号を処理して、受信側が送信できる以上の送信を避ける必要があるためです。扱う。

実用的な場合は、フロー制御のためにシリアルデータストリームから帯域外の追加信号を使用することをお勧めします。追加の信号線を使用できる直接配線接続では、使用中のハードウェアハンドシェイクが見つかり、これらの文字が他の用途に使用できるようになります。

もちろん、今日のターミナルウィンドウは実際の物理シリアルポートを使用しておらず、スクロールバーがあり、ソフトウェアハンドシェイクはまったく必要ありません。しかし、慣習は維持されます。

リチャード・ストールマンは、emacsの最初のリリースでCtrl + Sをインクリメンタル検索にマッピングすることについて苦情を受け、7ビットのソフトウェアフロー制御接続に依存しなければならないユーザーには共感的ではなかったという主張を思い出します。