SIGINTシグナルを受信したとき、bashは何をしますか？
このページには次のように書かれています。
Bashが対話型の場合、トラップがない場合、SIGTERMを無視し（ `kill 0 'が対話型シェルを強制終了しないように）、SIGINTをキャッチして処理します（待機組み込みが中断可能になるように）。 BashがSIGINTを受信すると、実行中のループから抜け出します。
通常、プログラムがSIGINT信号を受信すると、プログラムは終了します。ただし、bashは、SIGINTシグナルを受信しても終了せず、代わりに「実行中のループから抜け出します」。どういう意味ですか？
これは、その時点でbashが実行している組み込みおよびループが中止されることを意味します。 bashでSIGINT効果を実現するには、次を使用します。 Ctrl+D
結局、bashは壊れています。シェルプロセスがsigintを処理する方法は、sigintをキャッチし、すべての処理を停止して、保留中のすべてのforgroundプロセスが終了するのを待つことです。現実的には、SIGINTがフォアグラウンドで実行されているすべてのものを中断してはならない理由はありません。これが、プロセスグループが何年も前に作成された理由です。 bashがユーザーによって与えられるすべての「コマンド」は、同じpgroup内のプロセスをフォークする必要があり、シグナルが転送されるのはそのpgroupです。 pgroupが正しく使用されている場合は、シグナルを転送する必要はありません。フォークされた各プロセスは、デフォルトでbashと同じシグナル処理を行う必要があるためです。 Nohupを使用すると、フォークされたすべてのプロセスでsighup ==が無視されます。
Bashで見落とされていた元のunixシェル信号処理とプロセス関係については多くの詳細がありました。特にシェルスクリプトへのSIGINTは、シェルスクリプト全体を完全に停止する必要があります。ループから抜け出して、SIGINTが原因で前の作業が終了しなかったために、ファイルを破壊する可能性のある処理をさらに開始する可能性があります。
はい、トラップステートメントはよりクリーンに終了するのに役立ちます。ただし、元のUNIXシェルの実装では必要ありませんでした。これは主に、一時ファイルの使用またはその他の同様の詳細のクリーンアップメカニズムでした。現在、必要なときにシェルを終了させる必要があり、そのため、簡単に中断できる信頼できるシェルスクリプトを作成することが困難になっています。