Ctrl-S / XOFF のプロセスへの影響

Ctrl-S / XOFF のプロセスへの影響

実行中に、apt upgrade誤ってそのターミナル ウィンドウにCtrl- を送信してしまいました。S

今、私はXOFF、、、そしてテレタイプに関する新しいことを知りました。XONCtrlQ

「一時停止」された端末にCtrl-を送信すると、作業を続行しました。Qapt

について読んだところ、 で何が起こったのか、または を受け取るコマンドで一般的に何が起こるのかがXOFFわかりません。はディスプレイの更新を停止しますが、これは知っておいてよいことですが、まだ実行中なのでしょうか?aptXOFFhtophtop

まだ実行中ですかapt? それとも事実上一時停止、フリーズしましたapthtop?

どうやら、プロセスはXOFF'd 中でも入力を受け取ることができるため、まだ実行中です。

何が起こっているのでしょうか? たとえば、プログラム カウンターは、プログラム カウンターの増加を単に停止するのではなく、プログラムをフリーズさせるようです。

XOFF を処理するためにコマンドがどのようにプログラムされているかによって異なりますか? 基本的な Linux コマンドで期待できる一般的な動作はありますか?

注記それこれapt同様の質問には、プログラム自体で何が起こっているかについては触れられていないため、私の質問に対する回答は含まれていません。たとえば、プログラムが黙って実行され続けたのか、それともフリーズ/一時停止されたのかはわかりません。

答え1

すでにご存知のとおり、XONおよびはデフォルトで+および+XOFFにバインドされており、CtrlSCtrlQソフトウェアフロー制御文字と原則として遺物紙に印刷するテレタイプ端末の時代これらは、受信機器 (多くの場合、紙のプリンタ) がリモートの送信者からの入力に追いつけない場合に使用されました。

現在では紙のテレタイプは使われていないが、その背後にあるアイデアは「端末」のソフトウェアフレームワークの中にまだ残っている(例えば、ここそしてTTYの歴史に関する非常に素晴らしい記事) は、オリジナルの紙ベースの端末で使用されていた概念の一部を継承し、現在でも実装しています。その 1 つが、フロー制御文字を解釈する機能です。

通常、「コンソール上」で実行されているプログラム、つまり疑似端末に接続されているプログラムは、デフォルトで端末によってキャッチされるXONおよび文字を見ることができません。端末での標準的な動作は、プログラムから受信した出力の印刷を停止することです。プログラム自体は影響を受けず、バックグラウンドで実行され続けますが、 が再度受信されるまで、出力はユーザーに「送信」されません。XOFFXOFFXON

プログラムを作成し、これらの入力文字を明示的に受信したい場合は、tcsetattr()プログラム内のシステムコールを使用して、フラグを介してソフトウェアフロー制御を無効にすることができますIXOFFここでは、例えば) -nanoそれは、 例えば。

答え2

htopディスプレイの更新が停止します。これは知っておくとよいことですが、htop[Ctrl-S を入力した後] はまだ実行されていますか?

はい、もちろんです。htopまたは、他のコマンドは Ctrl-S によって停止またはフリーズされません。

termiosIXON設定は のようには動作しませんISIGVSTOP(Ctrl-S) またはVSTART(Ctrl-Q) 文字を入力しても、ターミナルで実行中のプロセスに信号は送信されません。

確認するのはとても簡単です。2つのターミナルを開いて、最初のターミナルで次のように入力します。

tail -f /tmp/file

そして2番目

cat > /tmp/file

次に、2 番目のターミナルで Ctrl-S と入力し、行を盲目的に入力し続け、最後に Enter キーを押します。最初のターミナルの画面に表示されます。 の代わりにcatシェルで、 のようなコマンドの場合はrm ...、画面にエコーバックされることなく実行されます。

XOFF を受信するコマンドで一般的に何が起こるか。

このコマンドは「XOFF を受信しません」。すべてターミナル ドライバー内で処理されます。アプリケーションの観点からは、何も起こりません。プログラムが大量の出力を送信し続ける場合 (または termiosECHO設定がオン (デフォルト) で、大量の入力を受信し続ける場合)、ターミナルへの書き込み (またはそれぞれの読み取り) は、Ctrl-Q が受信されるまで、ある時点でブロックされます。

関連情報