キーボードから信号を受信するアプリケーションは誰が決定しますか？

ターミナルのキーボードからの信号に関する私の現在の理解は、（私の観測をグーグルで見つけられるものにマップしようとすることに主に基づいています）次のとおりです：

• ユーザーがCcを押す
• これは、cの7ビットASCII値から左端の2ビットをクリアすることにより計算されるバイトとして、端末の入力バッファに送信されます。

この後、実際に霧が発生し始めます。これは、どの入力が端末（stty）で行われる信号を意味するためです。ターミナル自体がプロセスにシグナルを送信していることを意味すると思います。しかし、私もその端末はそれを読んでいるアプリケーションについて知りません。

端末のキーボードで信号を送信すると、エンドツーエンドでどのように機能しますか？

が押されているC間に押すとCtrl、キー押下とそれに続くキーリリースX11イベントがターミナルエミュレータに送信されます。

そのイベント（通常はキーを押すイベント）で、ターミナルエミュレーターは、0x3バイト（^C）を擬似ttyデバイスのマスター側のファイル記述子に書き込みます。

場合isigのtermiosは、デバイスの設定であり、場合にintr設定がその0x3のバイトに設定され、その後、カーネルは、すべてのメンバーにSIGINT信号を送信するフォアグラウンドプロセスグループの端末装置（PTY装置に記憶された他の属性）の。その場合、0x3バイトはptyのスレーブ側での読み取りに使用できなくなります。

通常はsetpgid()、シェルジョブのプロセスグループ（を使用）を作成し、フォアグラウンドに配置する（tcsetpgrp()ptyデバイスの属性を設定する）かどうかを決定する対話型シェルです。

たとえば、対話型シェルのプロンプトで実行する場合：

foo | bar

シェルは、2つのプロセス（それが実行されると、新しいプロセスグループを開始fooし、barその標準入力/出力管とを接続した後）とプットフォアグラウンドでそのグループ。Ctrl-Cを押すと、両方のプロセスがSIGINTを受け取ります。

に：

foo | bar &

同じですが、プロセスグループはフォアグラウンドに置かれていません（シェルはそれを待機しないため、他のコマンドを入力できます）。これらのプロセスはCtrl-CでSIGINTを取得しませんが、ttyデバイスから読み取ろうとすると中断される可能性があります。

さらに読む：各擬似端末（PTY）コンポーネント（ソフトウェア、マスター側、スレーブ側）の責任は何ですか？