たとえば、Linux bashスクリプトでは次のようになります。
exec /usr/lib/4.5/mono-service.exe ./AudioVideoRecorder.exe "$@"
、その部分なしで実行するexec
のではなく、そのコマンドを使用する必要があるのはなぜですか?exec
答え1
短い答えは次のとおりです。必ずしもそうではありませんが、おおよその費用が節約されます。1ミリ秒CPU時間(最新のCPUの場合)(それ以降は何も実行されないため、exec
スクリプトの終わりにのみ必要です)exec
より長い答えは次のとおりです。
Exec
現在のプロセスのプロセスイメージを、実行中の実行可能ファイルのプロセスイメージに置き換えます。これは、実行時にexec
ingを実行するシェルプロセスが完全に破壊され、edプログラムに置き換えられることを意味しますexec
。これが完了しない場合、exec
シェルはそれ自体に分岐し、分岐で実行し、子プロセスが終了するのを待ち、戻り状態を収集し、後で別のコマンドを実行することを望みます(fork
+exec
は新しいコマンドが生成される標準プロシージャです)。 。ないので、それはfork
完全な時間の無駄であり、ただし、時間を節約する方が良いですfork
。
ほとんどの意図と目的にとって、これは基本的にUnicesでプロセスがどのように作成されるかについての知識に基づいた微細最適化です。
メモ:(ありがとうございます。 イルカチョ)わずかに異なる意味は、スクリプトを生成したプロセスが潜在的に実行されているプログラムが終了する方法に興味があるかどうかです。潜在的に実行中の子プロセスが正常に終了すると、シェルスクリプトは最後に待機した終了状態を自己終了状態に渡すため、実行形式と非実行形式は同じです。ただし、子プロセスがsignalによって終了すると、n
シェルはそれを終了状態に変換して、128+n
シグナルを送信した情報を効果的に失います。 (>128
通常、そのように子が定期的に終了コードを使用して終了しないと確信している場合、情報は失われません。)execを実行すると、仲介者シェルがなくなり、終了ステータス情報は実行スクリプトの呼び出し元に直接送信されます。 (そして仲介者シェルがないため、子プロセスが終了したかどうか、またはシグナルを受け取ったかどうかに関する情報が保持されます)、終了コードにマージします)。 (望むよりプロセスを待っている(2)より多くの情報を知りたい場合)。