printfがyashの組み込みであるかどうかに関するこの質問から、POSIX標準を引用するこの答えが出てきます。

答えは、POSIX検索シーケンスは目的のコマンドの外部実装を見つけ、シェルがそれを組み込みとして実装している場合、組み込みを実行することであると指摘しています。（特別なビルトインではないビルトインの場合）

POSIXには、内部実装の実行を許可する前に、外部実装が存在するというこの要件があるのはなぜですか？

それは... arbitrary意的だと思うので、私は興味があります。

これは「あたかも」ルールです。

簡単に言えば、実装が標準の外部コマンドをシェル組み込みとしても使用可能にすることを決定した場合、ユーザーが見るシェルの動作は変わらないはずです。

私が/unix//a/496291/5132で示した（一方の）PD Korn、MirBSD Korn、およびHeirloom Bourneシェルの動作の対比。（一方で）Z、93 Korn、Bourne Again、Debian Almquistシェル。そして（握り手で）渡辺貝がこれを強調しています。

printfビルトインとしてないシェルの場合、/usr/binから削除PATHすると、printf動作を停止します。適合モードで渡辺シェルが示すPOSIX適合動作は、同じ結果を引き起こします。printf組み込みのシェルの動作は、外部コマンドを呼び出しているかのようです。

一方、非準拠シェルのすべての動作は、/usr/binから削除された場合は変更されず、外部コマンドを呼び出しているかのようには動作しPATHません。

標準が保証しようとしているのは、シェルがあらゆる種類の通常外部コマンドを組み込み（またはそれらを独自のシェル関数として実装）できることであり、組み込みと同じ動作を引き続き行うことができますPATHコマンドが見つからないように調整する場合は、外部コマンドを使用します。 PATH起動できるコマンドを選択および制御するためのツールのままです。

（/unix//a/448799/5132で説明されているように、何年も前に人々は、何がオンになっていPATHたかを変更することでUnixの個性を選択しました。）

コマンドを見つけることができるかどうかに関係なく、コマンドを常に機能させることPATH は、実際には、通常は外部コマンドをビルトインするポイントです。（これが、私のnoshツールセットprintenvがバージョン1.38で組み込みコマンドを取得した理由です。実際、これはシェルではありませんが。）

ただし、標準では、関数を呼び出す他の非シェルプログラムから見られるように、シェルから起動していない通常の外部コマンドに対して同じ動作が見られるという保証が与えられており、シェルは魔法のようにはできません他のプログラムが同じで見つけることができない通常の外部コマンドを（明らかに）実行します。すべてはユーザーの観点から一貫して機能し、その動作を制御するためのツールです。PATHexecvpe()PATHPATH

参考文献

• POSIX必須ユーティリティがシェルに組み込まれていないのはなぜですか？
• なぜechoはコマンドに組み込まれたシェルですか？
• bashはどのようにコマンドを実行しますか

それは非常に馬鹿げているので、デフォルトモードでそれを実装しているシェルはありません。

標準の理論的根拠とその例は、これがパスに関連付けられた通常のビルトインを持っている失敗した試みであり、ユーザーが自分のバイナリをその前に表示することでそれをオーバーライドできることを示唆しているPATH（例えばprintf、に関連付けられたビルトイン）を設定/usr/bin/printfすることにより、/foo/bin/printf外部コマンドによってオーバーライドできますPATH=/foo/bin:$PATH。

しかし、標準はそれを要求することにはなりませんでしたが、完全に異なるものを必要としました（また、役に立たず、予期していませんでした）。

詳細については、このバグレポートをご覧ください。最終的に受け入れられたテキストからの引用：

多くの既存の実装は、PATH検索を実行せずに通常の組み込みを実行します。この動作は規範的なテキストと一致せず、スクリプト作成者が特別に細工されたPATHを介して通常の組み込みユーティリティをオーバーライドすることはできません。さらに、その根拠は、作成者が PATHを変更することでビルトインをオーバーライドできるようにすることであると説明していますが、これは規範的なテキストには書かれていません。

FWIW、受け入れられたテキストから改訂された要件を実装するシェルも存在しないと思います。