Bashシェルがサブシェルでスクリプトを実行するのはなぜですか？これにはどのような利点がありますか？
ベストアンサー1
シェルはもともとシステムの「ユーザーインターフェース」と呼ばれ、次のような責任がありました。実装する手順（別名操作）。アクションを呼び出すために、シェルはカーネルにアクションを実行するように要求します。カーネルは、ジョブが使用するメモリとファイルを読み書きする権限を管理します。カーネルにプログラムを「実行」するように要求する基本的なアプローチは次のとおりです。クロス新しいタスク（新しいPID（プロセス番号）提供）実装する新しいPIDの新しいプログラム。カーネルはパラメータリストを受け取ります。
int execve(const char *filename, char *const argv[], char *const envp[]);
デフォルトでは、カーネルにfilenameパラメータを使用して実行するように要求しますargv[]。カーネルは要求された操作を実行し、プログラムが終了すると制御権は親プロセスに返されます。
シェルを次のように取る執行者これは、一部の通訳者が理解できるテキストファイルも実行できるプログラムのための明確な拡張です。これは#! /interpreterカーネルも理解する shebang メカニズムです。
したがって、シェルは「スクリプトを実行」することができますが（時には実行します）、最も自然な実行順序では、カーネルは他のプログラムのようにこれを実行する必要があります。つまり、プログラムをロードしてプロセス制御（PID）を提供する必要があります。
異なるPID内で実行されるプログラムは、親PPIDを汚染しないと予想される。つまり、1つのPIDを変更しても親PIDには影響しません。
したがって、「スクリプト」が実行されると（通常）新しいPIDが得られます。サブシェルと呼ばれるのか、サブシェルと呼ぶのかを混乱させることもありますが、重要なのは別のPID内で実行されることです。通常は子プロセス（PID）です。