シェルのユーティリティ依存関係

私はすべての* nixオペレーティングシステムの「レイヤー」アーキテクチャがカーネルシェルユーティリティ（「Inside Out」）であることを知っています。

しかし、実際にはそうではありません。すべてがカーネル上で実行され、シェルではなくスクリプト「ユーティリティ」にはシェルが必要ないため、特定のシェルに依存しません。

一部のプログラムでは、Waylandシンセサイザが必要なWaylandクライアントなどの他のプログラムが必要です。しかし、関連するシェルの一般的な階層化はありません。

私は「シェル」がUnixシステムでログインシェルとして使用される特定のシェルを参照していると仮定します。

コンピュータのソフトウェアは特定のシェルに依存する可能性が高いですが、プライベートログインシェルとして使用するシェルには依存しません（つまり、ログインシェルには依存しません）。なぜならこれはログインシェルです）。

スクリプトとして（または部分的にスクリプトとして）実装されているユーティリティは、たとえば他のシェルを使用して操作を実行できますが、ログインシェルがより難解なシェルの場合、/bin/shPythonスクリプトと同じように機能します。どのシェルを使用しても、誰にでも同じです。bashzshyash

Unixはマルチユーザーオペレーティングシステムなので、コマンドラインユーティリティとグラフィカルアプリケーションは、ユーザーがどのコマンドラインシェルを使用しても、同じ方法（「パイプライン」、つまりユーティリティ実行構文）で動作します。多少異なる場合がありますが、すべてのユーザーのシェルで一貫しています。）

ユーティリティプログラムの例を見てみましょう。使用シェルスクリプト、firefox一部のシステムの実行可能ファイルを参照してください（ブートファイルかもしれません）。実際 firefoxバイナリ）。 OpenMPIのようないくつかのタイプのコンパイラは、実際のコンパイラの周りのシェルスクリプトラッパーとして実装されています。同様に、これを実行するプログラムは、ユーザーがログインシェルとして使用するシェルに関係なく、同じ方法で動作します。

一方、たとえば、作成されたシェルスクリプトは次のようになります。zsh 〜しないだろう他のシェルで実行すると安定して動作します。スクリプトのインタプリタを別のスクリプトに置き換えると、スクリプトが破損する可能性が高いため、これは驚くべきことではありません（たとえば、Rubyインタプリタを使用してPerlスクリプトを実行すると失敗する可能性があります）。