ルートディレクトリが/記号で示されているのはなぜですか？
Googleでこれについていくつかの調査を行いましたが、結果は曇っていました。なぜ/記号は、ルートディレクトリを示すために使用されます。その背後に確かな理由はありますか？
スラッシュ_/_は、Unixライクなオペレーティングシステムのディレクトリを paths で区切る区切り文字です。この文字は1970年代に選ばれたようで、 事例 によると、理由はUnixの前身である に関連している可能性があります。 Multics オペレーティングシステムでは、_>_文字をパス区切り文字として使用していましたが、Unixの設計者は、_>_および_<_の文字を予約して、シェルコマンドラインは、マルチレベルのファイルシステムを導入するかなり前からありました。したがって、ファイルシステムを設計するときがきたとき、彼らはパス名要素の分離を表す別の文字を見つける必要がありました。
ここで注意すべき点は、1970年代に一般的に使用されているリアシーグラーADM-3A端末で、特に_~_文字を使用して家を表す習慣 があることです。ディレクトリの起点 、 / キーはの横にあります > キー：
ルートディレクトリが単一の_/_で示される理由は、ルートディレクトリがディレクトリ階層の最上位ディレクトリであり、他のディレクトリがその下にある可能性があるという事実に影響される可能性が高い規則です、通常、ルートディレクトリ以外の場所を参照する必要はありません。同様に、ディレクトリエントリ自体は表示されているディレクトリツリーの境界であるため、名前はありません。
最初の 階層型ファイルシステム は、今日のところ Multics 用に設計されています。設計は、RCによって 「2次ストレージ用の汎用ファイルシステム」 で説明されています。デイリーとPGノイマン。このファイルシステムの顕著な特徴は、ディレクトリが他のファイルと同様にディレクトリに含めることができるファイルであることです。ファイル構造はツリーを形成し、その中ですべての非リーフノードがディレクトリです。ツリーのルートは常にディレクトリです。各ファイルには、親ディレクトリ内で一意の名前（ エントリ名 ）があります。ルートディレクトリは別のディレクトリに含まれていないため、名前はありません。
ファイルを指定するには、ツリーのルートからのパスを記述する必要があります。 Multicsは パス名 の自然な構文を採用しました。ここで、Pがディレクトリへのパスであり、Fがファイルの名前である場合、P>Fは構文ですパスがFであるディレクトリ内のPというファイルの場合。
ディレクトリに負担をかけたくないときのために、Multicsには working directory の概念がありました。ディレクトリを示さない裸のファイル名は、作業ディレクトリ内のファイルとして解釈されます。
これらのルールを組み合わせると、fooは作業ディレクトリ内のファイルです。 foo>barは、作業ディレクトリの子ディレクトリfooなどにあるファイルです。これらのルールは相対パスを記述しますが、ルートディレクトリから始まる絶対パスを構築するには補足ルールが必要です。パス名を左から右に読むことは、ルートからツリーの葉に移動することに対応するので、ルートはパス名の左側にある特別なマーカーで示す必要があります。ファイル名が空になることはないため（混乱を招くことが多いため）、絶対パス名のマーカーとして便利な>で始まる相対パス名はありません。したがって、>fooはルートディレクトリのfooというファイルであり、>foo>barはルートディレクトリのbarというディレクトリのfooというファイルです、 等々。空の文字列である可能性があるルートディレクトリが残ります。ただし、空の文字列をパス名として使用するのは不便な場合が多いため、代わりに>が書き込まれます。これには、最初の文字が>の場合に限り、パス名が絶対であるという追加の利点があります。
Unixはこの設計をMulticsから採用しました。 Unixはコマンドシェルの出力リダイレクトに文字>をすでに使用していたため、その designers はパス名のディレクトリを区切るために別の文字/を選択しました。
Unixのパス名コンポーネントでは、C（カーネルの言語）の文字列を終了するnull文字とパス区切り文字として予約されているスラッシュの2文字のみを使用できません。さらに、パスコンポーネントを空の文字列にすることはできません。
したがって、パス名には、スラッシュとコンポーネントの2種類のトークンしかありません。
新しいトークンを追加せずにとすると、相対パスと絶対パスの2種類のパスのサポートをサポートしたいとします。さらに、名前のないルートディレクトリを参照できるようにしたいと思います（名前を付ける親がありません）。
スラッシュのみを使用して、相対パス、絶対パスを表し、ルートディレクトリを参照するにはどうすればよいですか？
（新しいトークンの導入以外の）言語を拡張する最も明白な方法は、新しい構文を作成することです。無効な構文であるトークンの組み合わせに新しい意味を与えます。
スラッシュで始まるパスは意味をなさないので、「このパスは相対パスではなく絶対パス」を示すマーカーとして先頭のスラッシュを使用しないでください。
スラッシュしか含まれていないパスも無効なので、「ルートディレクトリ」という意味を割り当ててください。
絶対パスがルートディレクトリから検索を開始するため、これら2つの意味は結びついています。つまり、先頭のスラッシュは次の意味を持つと見なすことができます。
- ルートディレクトリに移動し、スラッシュ文字を使用します。
- パスにさらにマテリアルがある場合は、相対パスとして処理します。それ以外の場合は完了です。
次に、末尾のスラッシュを挿入することもできます。これは、「このパスは、最後のパスコンポーネントが通常のファイルやその他の種類のオブジェクトではなくディレクトリの名前であることを表明します。末尾のスラッシュは、次のようにそのディレクトリを示します。先頭のスラッシュがルートディレクトリを示す方法。」
上記のすべての構文で、二重のスラッシュ、トリプルのスラッシュなど、未割り当ての意味を持つ構文がまだあります。
なぜ別のトークンを導入し、別の方法で実行しないのですか？これはおそらく、設計者が一般的に最小限のアプローチをとったためです。 （なぜedエディターは?何か間違ったことをしたとき？）スラッシュは入力が簡単で、シフトする必要はありません。 2つのトークンタイプ（コンポーネントとスラッシュ）のみのパス言語は、覚えて使用するのが簡単です。
もう1つの重要な考慮事項は、文字列表現のみを使用してパスを簡単に操作できることです。たとえば、新しい親ディレクトリへの絶対パスを簡単に「再ルート」できます。
OLD_PATH=/old/path
NEW_HOME=/new/home
NEW_PATH="$NEW_HOME$OLD_PATH" /new/home/old/path
先頭のドル記号など、絶対パスを他の方法で指定した場合、これは機能しません。
OLD_PATH=^old/path # ^ means absolute path
NEW_HOME=^new/home
# now we need more string kung-fu than just catenation
NEW_PATH="$NEW_HOME/${OLD_PATH#^}"
このタイプのコーディングは、Unixスタイルのパスを処理するときに必要になる場合がありますが、それよりも少ない場合があります。