Ctrl-S / XOFFのプロセスへの影響
実行中apt upgradeに、誤ってCtrl-Sをそのターミナルウィンドウに送信しました。
今、私の知っているXOFF、XON、Ctrl- Q、およびテレタイプについて新しい何か。
「一時停止」端末にCtrl-を送信すると、作業を続行しました。Qapt
について読んだところXOFF、で何が起こったのaptか、またはを受け取るコマンドで一般的に何が起こったのかは私にはわかりませんXOFF。htop表示の更新を停止します。これは知っておくとhtop便利ですが、まだ実行中ですか？
たapt、まだ実行されていますか？それともapt、htop効果的に一時停止、凍結されましたか？
どうやら、プロセスはXOFF'dの間、まだ入力を受け取ることができるので、まだ実行中です。
何が起こっている？たとえば、プログラムカウンタは、プログラムカウンタのインクリメントを停止して、プログラムをフリーズするだけではないようです。
XOFFを処理するようにコマンドがどのようにプログラムされているかに依存しますか？基本的なLinuxコマンドで期待できる一般的な動作はありますか？
回答
htop表示の更新を停止します。これは知っておくとhtop便利ですが、[Ctrl-Sを入力した後]まだ実行されていますか？
そのとおり。htopまたは他のコマンドはCtrl-Sによって停止またはフリーズされません。
IXONtermiosの設定は次のように動作しませんISIG。タイピングVSTOP（Ctrlキーを押しながらS）またはVSTART（Ctrlキーを押しながらQ）の文字が、端末で実行中のプロセスに任意のシグナルを送信しません。
それを確認するのはとても簡単です。2つの端子を開きます：最初の入力で
tail -f /tmp/file
そして2番目に
cat > /tmp/file
次に、2番目の端末でCtrl-Sと入力し、続けて行を盲目的に入力してからEnterキーを押します。それらは最初の端末の画面に表示されます。catシェルではなく、のようなコマンドの場合rm ...、画面にエコーバックすることなく実行されます。
XOFFを受信するコマンドで一般的に何が起こるか。
このコマンドは「XOFFを受信」しません。それはすべてターミナルドライバ内で処理されます。アプリケーションの観点からは、何も起こりません。プログラムが大量の出力を送信し続ける場合（またはECHOtermios設定が-デフォルト-であり、大量の入力を受信し続ける場合）、ターミナルへの書き込み（またはそれぞれの読み取り）は、Ctrl-Qが受信されるまである時点でブロックされます。
あなたが既に知っている、ことのようXONとXOFFに結合され、Ctrl+SとCtrl+Qデフォルトでは、あるソフトウェアフロー制御文字とから原則遺物で紙の印刷テレタイプ端末の昔は。これらは、受信機器（多くの場合、紙のプリンター）がリモート送信者から送信された入力に対応できない場合に使用されていました。
現在、紙のテレタイプは使用されていませんが、その背後にある考え方は、「端末」のソフトウェアフレームワークに保持されています（たとえば、こことTTYの歴史に関するこの非常に優れた記事を参照）。元の紙ベースの端末で使用されていた概念-1つは、フロー制御文字を解釈する機能です。
通常、「コンソール上」で実行されているプログラム、つまり疑似端末に接続されているプログラムは、デフォルトで端末によってキャッチされているため、XONおよびXOFF文字を表示できません。標準の動作でXOFFは、出力の印刷を停止します。プログラムから受け取ります。それ以外の場合、プログラム自体は影響を受けず、バックグラウンドで実行され続けXONます。が再度受信されるまで、出力のみがユーザーに「転送」されません。
あなたがプログラムを書いて、明示的にこれらの入力文字を受信したい場合は、使用することができますtcsetattr()経由でソフトウェアフロー制御を無効にするために、あなたのプログラムにシステムコールをIXOFFフラグ（参照例えば、ここでは） -nanoそれを行う例えば、。