シェルは無駄な終了コマンドを最適化することを許可されていますか？

シェルは、などの終了することがわかっているおそらく役に立たない（または部分的に役に立たない）コマンドを実行するように要求された場合、cat hugeregularfile.txt > /dev/nullそのコマンドの実行をスキップできますか （または、より安価な同等のコマンドを実行できtouch -a hugeregularfile.txtますか？）

より一般的には、外部で観察可能な動作が抽象マシンが評価した場合に限り、ソースコードに変換を実行できるという点で、シェルはCコンパイラに似ていますか？

編集

Nota Bene：当初提起された私の質問には、シェルがこれらの最適化を行うことが許可されているかどうか、またはそれらを行うことができる実装が存在するかどうかではなく、尋ねられました。理論は実践よりも理論に興味がありますが、どちらも大歓迎です。

いいえ、それは悪い考えです。

cat hugeregularfile.txt > /dev/nullとtouch -a hugeregularfile.txt同じではありません。cat出力をにリダイレクトしても、ファイル全体が読み取られ/dev/nullます。そして、ファイル全体を読むことはまさにあなたが望むものかもしれません。たとえば、後の読み取りが大幅に速くなるようにキャッシュするため。シェルはあなたの意図を知ることができません。

同様に、Cコンパイラは、読んだものを見ていない場合でも、ファイルの読み取りを最適化することはありません。

いいえ、/dev/null名前は単なる名前であり、他のデバイスまたは「通常」データシンク以外のファイルに使用できます。

そのため、シェル（または他のプログラム）は、名前に基づいて、書き込み先のファイルがデータに対して「実際に」何かを実行しているかどうかを知りません。また、たとえば、ファイル記述子が実際には何もしていないことを判断するために、シェルプログラムが実行できるシステム呼び出しはありません。

Cプログラムのアウェイコードの最適化との比較は機能しません。シェルには、Cコンパイラがソースコードに対して持つ全体的な概要がないためです。/dev/nullCコンパイラーが動的にリンクする関数呼び出しのコードを十分に知らないため、呼び出しを行わないように、シェルは例を最適化するほど十分に知りません。

実行中のコマンドは最適化されません（そして、なぜそうすべきではないかを示す多くの細かい回答を既に受け取っています）が、フォーク、パイプ/ソケットペア、読み取りを最適化する場合があります。最適化の種類：

• 最近のほとんどのシェルでは、スクリプトの最後のコマンドは、いくつかtrapのが設定されていない限り、通常シェルのプロセスで実行されます。で、例えばsh -c ls、ほとんどの sh実装（bash、mksh、ksh、zsh、yash、いくつかのバージョンではash）を実行するプロセスをフォークしないであろうls。
• ではksh93、コマンド置換は、外部コマンドが呼び出されるまでプロセスをパイプまたはフォークしません（$(echo foo)たとえばfoo、パイプ/ソケットペアまたはフォークなしで展開します）。
• readいくつかのシェルの組み込み（bash、AT＆T ksh）は、stdinがシーク可能であることを検出した場合、シングルバイトの読み取りを行いません（この場合、大きな読み取りを行い、読み取ることを意図した最後までシークします）。

を見るcat hugeregularfile.txt > /dev/nullと、シェルはアクションが役に立たないことを信じることcatができません— シェルの一部ではなく、理論的にも実際にも何でもできます。

たとえば、ユーザーが実行可能ファイルを名前を変更したことrmにcat、ファイルを削除する、すなわち、外部から観察可能な行動をし、突然ラインを実行します。

ユーザーは、catそのバージョンをコンパイルして無限ループになる可能性があるため、シェルは、提案されているように「終了することがわかっている」と想定することはできません。

誰かがcat意図したとおりに動作するバージョンをインストールした可能性がありますが、適切な権限で実行された場合にルートキットをインストールするという余分な副作用があります。