システムコールとシェルコマンド/ユーティリティの関係
POSIXでは、
システムコール関数は、シェルにコマンドまたはユーティリティがあるとは限りませんが、頻繁にありますか？
どの種類のシステムコールに対応するコマンドまたはユーティリティがシェルにあり、どの種類のコマンドまたはユーティリティに対応するシステムコールがあるかについての経験則はありますか？
システムコールおよび対応するシェルコマンドまたはユーティリティの場合、コマンドまたはユーティリティは常にシステムコールと同じ方法で実装されますか？実装はシステムコールにも基づいていますか？
- システムコール関数は、シェルにコマンドまたはユーティリティがあるとは限りませんが、頻繁にありますか？
時々。公開するのに役立つシステムコールは、通常公開されます。ディレクトリを変更できなかったシェルは、あまり便利なシェルではありません。 chdirのようないくつかは、それらを呼び出したプロセスにのみ影響を与えることができるため、シェル組み込みとして実装されます。その他は小さなプログラムとして実装されます。さらに他のものはまったく公開されていません：非常にシェルから直接mmapを呼び出す理由はほとんどないので、自分でラッパーを作成しない限り、呼び出すことはできません（とにかく役に立たない）。
- シェルのどの種類のシステムコールに対応するコマンドまたはユーティリティがあり、シェルのどの種類のコマンドまたはユーティリティに対応するシステムコールがあるかについての経験則はありますか？
標準的な対応や経験則はありません。名前は何でもかまいません。たとえば、rmはunlinkシステムコールの観点から実装されます。ただし、またこれを行うunlinkコマンドもありますが、ほとんどのコマンドラインオプションがなく、基本的には単なるラッパーです。また、pipe syscallは、対応するreadsおよびwritesとともに、|構文を介して公開されます。
man syscallsはシステムコールのリストを提供するはずです。
- システムコールおよび対応するシェルコマンドまたはユーティリティの場合、コマンドまたはユーティリティは常にシステムコールと同じ方法で実装されますか？実装はシステムコールにも基づいていますか？
ユーティリティはシステムコールを使用するだけです。実際、これがユーティリティがこれらのことを実行できる唯一の方法です。たとえば、ファイルを削除したり、権限を変更したりすることはできませんでしたなしで直接または間接にかかわらず、syscallメカニズムを通過します。
（そうでない場合はどうなるか想像してみてください。ファイルを削除したいすべてのプログラムは、独自のファイルシステムドライバーとハードディスクドライバーを実装する必要があります。また、すべてのプログラムがチェックを担当するため、セキュリティもありません。独自の権限。代わりに、syscallを使用するだけで、カーネルがすべてを把握します。）