スラッシュ / Unix ライクなオペレーティング システムでパス内のディレクトリを区切る区切り文字です。この文字は 1970 年代に選択されたようで、逸話的なソースによると、その理由は Unix の前身である Multics オペレーティング システムが > を使用していたことに関連している可能性があります。 文字をパス区切り文字として使用しますが、Unix の設計者はすでに文字 > を予約していました と < マルチレベルのファイル システムを導入するかなり前に、シェル コマンド ラインで I/O リダイレクションを指定するためでした。そのため、ファイルシステムを設計する段階になったとき、パス名要素の分離を表す別の文字を見つける必要がありました。
ここで注意すべきことは、1970 年代に一般的に使用されていた Lear-Siegler ADM-3A 端末で、~ ホーム ディレクトリを表す文字、/ キーは > の隣にあります キー:
ルートディレクトリが単一の / で示される理由について 、これは、ルート ディレクトリがディレクトリ階層の最上位のディレクトリであり、他のディレクトリがその下にある場合でも、通常はルート ディレクトリ以外のものを参照する理由がないという事実によって影響を受ける可能性が最も高い規則です。 .同様に、ディレクトリ エントリ自体には名前がありません。これは、表示されるディレクトリ ツリーの境界であるためです。
今日知られている最初の階層型ファイル システムは、Multics 用に設計されました。この設計については、R.C. Daley と P.G.ノイマン。このファイルシステムの顕著な特徴は、ディレクトリが、他のファイルと同様にディレクトリに含めることができるファイルであることです。ファイル構造はツリーを形成し、リーフ以外のノードはすべてディレクトリです。ツリーのルートは常にディレクトリです。各ファイルには、その親ディレクトリ内で一意の名前 (エントリ名) があります。別のディレクトリに含まれていないため、ルート ディレクトリには名前がありません。
ファイルを指定するには、ツリーのルートからのパスを記述する必要があります。 Multics は、if P のパス名に自然な構文を採用しました。 はディレクトリへのパスで、F はファイルの名前で、P>F F というファイルの構文です。 パスが P のディレクトリ内 .
ディレクトリに負担をかけたくない場合のために、Multics には作業ディレクトリの概念がありました。ディレクトリを示さないベア ファイル名は、作業ディレクトリ内のファイルとして解釈されます。
これらのルールを組み合わせると、foo 作業ディレクトリ内のファイルです。 foo>bar 子ディレクトリ foo 内のファイルです 作業ディレクトリなど。これらの規則は相対パスを記述しますが、ルート ディレクトリから始まる絶対パスを構築するには補足規則が必要です。パス名を左から右に読むことは、ツリーのルートからリーフへの移動に対応するため、ルートはパス名の左側にある特別なマーカーで示されます。ファイル名が空になることは決してないため (混乱を招くことが多いため)、相対パス名が文字 > で始まることはありません。 、絶対パス名の便利なマーカーになります。したがって、>foo foo というファイルです ルートディレクトリ >foo>bar bar というファイルです foo というディレクトリに ルートディレクトリなど。これにより、空の文字列である可能性があるルート ディレクトリが残ります。ただし、空の文字列をパス名として使用するのは不便な場合が多いため、代わりに > と記述します。 、これには、最初の文字が > である場合にのみパス名が絶対であるという追加の利点があります .
Unix は Multics からこの設計を採用しました。 Unix はすでに文字 > を使用していたため、 コマンド シェルの出力リダイレクト用に、設計者は別の文字 / を選択しました パス名でディレクトリを区切ります。
Unix のパス名コンポーネントでは、2 つの文字のみを使用できません:C (カーネルの言語) で文字列を終了するヌル文字と、パスの区切りとして予約されているスラッシュです。さらに、パス コンポーネントを空の文字列にすることはできません。
したがって、パス名には、スラッシュとコンポーネントの 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 スタイルのパスを扱う場合に必要になる場合もありますが、それほど多くはありません。