cdが/binのファイルではないのはなぜですか? [コピー]

cdが/binのファイルではないのはなぜですか? [コピー]

重複の可能性:
CDはなぜプログラムではないのですか?

一般的に使用されている他のすべてのユーティリティ(などls, cp, rm)は、実際には/ binにあるファイルであることがわかりました。しかし、そうではcdありません。また、他のバイナリディレクトリ(例:など)にもありません/usr/bin, /bin, /sbin

なぜこれが起こるのですか?

答え1

cd内蔵ケース。したがって、別々の実行可能ファイルではなく、シェル自体の一部です。

デフォルトでは、組み込み関数には2つのカテゴリがあります。

  • 特殊組み込み機能シェルと密接に接続されており、独立して実装できないか、それを行うことが機能的な意味を持たないため、実装できません(主にシェル制御に関連しています)。彼らは特定の特徴を持っているので、「特別」と呼ばれます。エラー処理と変数の割り当て意味論。
  • 一般的な組み込み機能通常、パフォーマンス上の理由からシェルの内部(たとえばcd)を操作またはそうすることは技術的により簡単なため、シェルで実装されます。場合によっては、通常の組み込みが組み込まれていない形で存在することがあります。後者の場合の例は、echoすべての現代のシェルで実装されていますが、主に歴史的な理由で存在することです/bin/echo

重要な機能を組み込む必要があるもう1つの理由は、システムに致命的なことが発生してもコア機能にアクセスでき続けることです。たとえば、共有ライブラリが破損しているかアクセスできない場合、/bin/sbin

答え2

一部のUnixの歴史的資料では、cdと言います。以前は(非常に初期)Unix開発期間の外部コマンドです。これは変更できる特別なコマンドです。現在のディレクトリ。

次の事実から、この歴史的状態の始まりを見ることができます。持つ/usr/bin/cd は、シェル組み込みコマンドに加えて実際のコマンドとして使用されます。しかし、現在のシステムで実際に使用されているかどうかは不明です。

これは、外部コマンドとしてUnix開発者がシェル組み込みコマンドを使用できるようになった後に削除された一時的なソリューションでした。単純なシステムコールだけで十分な完全なコマンド(自己プロセス、ディスクからのロードなどが必要です)を持つのは高価です。だから組み込み関数になり、それ以来状態は変わりませんでした。

ほとんどすべてのコマンドを含むシェルを作成できます。これは単なる設計上の矛盾です。例えば、CPここで言及されている機能はこれのための良い候補かもしれません。この組み込み機能は、すでにMS-DOSの一部のシェルに実装されています。ただし、Unixではプロセスを作成して開始する方が安く、他のプロセスで実装できない場合を除き、機能を内部的に開発する必要はありません。これには以下が含まれますCD限界値出口、変数演算、制御フローコマンド(もし~のためしかし、ちょっと待ってください。

関連情報