キーボードから信号を受信するアプリケーションを決定するのは誰ですか？
端末のキーボードからの信号についての私の現在の理解は、（私の観察をグーグルで見つけることができるものにマッピングしようとすることに主に基づいています）以下です：
- ユーザーがC-cを押す
- これは、cの7ビットのASCII値から左端の2ビットをクリアすることによって計算されるバイトとして端末の入力バッファーに送信されます。
この後、それは本当に霧になり始めます、なぜなら、どの入力がどの信号をターミナル（stty）で行うかを意味するからです。端末自体がプロセスにシグナルを送信していることを意味すると思います。しかし、その端末はそれを読んでいるアプリケーションを認識していません。
端末でキーボードを使用して信号を送信する方法
押す C ながら Ctrl が押されると、端末エミュレーターにkeypressに続いてkeyrelease X11イベントが送信されます。
そのイベント（通常はキーを押す）で、ターミナルエミュレーターは0x3バイト（_^C_）を疑似ttyデバイスのマスター側のファイル記述子に書き込みます。
デバイスのisig termios設定がオンであり、intr設定がその0x3バイトに設定されている場合、カーネルはSIGINTシグナルを端末デバイスのフォアグラウンドプロセスグループ（ptyデバイスに格納されている別の属性）。その場合、0x3バイトはptyのスレーブ側での読み取りに使用できなくなります。
これは通常、シェルジョブのプロセスグループ（setpgid()を使用）を作成し、フォアグラウンドに配置する（tcsetpgrp()を使用してptyデバイスの属性を設定する）かどうかを決定する対話型シェルです。 。
たとえば、対話型シェルのプロンプトで実行すると、次のようになります。
_foo | bar
_シェルは2つのプロセスで新しいプロセスグループを開始し（stdin/outをパイプで接続した後、fooおよびbarを実行します）、そのグループをフォアグラウンドに配置します。 Ctrl-Cを押すと、両方のプロセスがSIGINTを受け取ります。
に：
_foo | bar &
_同じですが、プロセスグループはフォアグラウンドに置かれません（シェルも待機しないため、他のコマンドを入力できます）。これらのプロセスはCtrl-CでSIGINTを取得しませんが、ttyデバイスから読み取ろうとすると中断される可能性があります。