POSIX仕様全体を通して、実装が2つの/
で始まるパスを特別に処理できるようにするための規定( 1 、 2 、 ...)があります) 。
POSIXアプリケーション(すべてのPOSIX準拠システムに移植できるようにPOSIX仕様に作成されたアプリケーション)は、//foo/bar
が/foo/bar
と同じであると想定できません(ただし、///foo/bar
は/foo/bar
と同じであると想定できます)。
さて、//foo
を特別に扱うPOSIXシステム(歴史的であり、現在も維持されている)は何ですか?私は信じました(私は 間違っていることが証明されました )。POSIXプロビジョニングはMicrosoftによってUnixバリアント(XENIX)とおそらくWindows POSIXレイヤー(だれかそれを確認できますか?).
これはCygwinによって使用されます。Cygwinは、Microsoft WindowsのPOSIXのようなレイヤーでもあります。 Microsoft以外のWindowsシステムはありますか? OpenVMS?
//foo/bar
が特別なシステムでは、それは何のために使用されますか? //Host/path
はネットワークファイルシステムにアクセスしますか?仮想ファイルシステム?
Unixライクで実行されている一部のアプリケーション(システムのAPIでない場合)は、//foo/bar
パスを特別に扱いますか(そうでなければ、/foo/bar
をファイルシステム上のパスとして扱うコンテキストで)?
編集、私は以来 オースティングループのメーリングリストで質問しました 仕様の//foo/bar
処理の起源について、そして議論は興味深い読み物です(少なくとも考古学の観点から)。
これは、これまでに出された回答のまとめと索引です。この投稿はコミュニティウィキであり、100人以上の評判を持つ誰でも編集でき、誰からも評判は得られません。自由に回答を投稿して、ここにリンクを追加してください(または、私が回答するのを待ってください)。理想的には、この回答は要約である必要があります(他の個々の回答には詳細があるが、短いエントリ)。
//Host/file
ネットワークファイル共有パスに使用されます。//pathname
要求を解決します、ネットワークファイルではありません。 例 。@BinaryZebra Apollo Domain/OS (確認済み)。 Official Description UNC(Universal Naming Convention) でも可能な //Host/path
表記の起源 ( も参照 、2-15ページ)として言及されています。
Donn Terry によると、ドメイン/ OSの POSIX仕様にその条項を含めるように要求した はHP(Apollo Computersを買収した)でした。
@jillagre Tektronix Utek( 確証 )、ここで//Host/path
は、分散ファイルシステム上のパスです。
//123/path
はノード上の/path
です123.(言及された QNX 6のドキュメントに記載 。)//Host/path
in(SVR4で廃止) RFS Remote File Sharing システム。//Host/path
に使用されます。//foo/bar
を特別に扱うアプリケーション//depot/A/B/C/D
はデポ内のパスを参照します。//
プレフィックスを使用します(データブロックに関連付けられたブレンドへ) 。Unixライクで実行されている一部のアプリケーション(システムのAPIでない場合)は、// foo/barパスを特別に扱いますか?
デポを参照するために//depot/A/B/C/D
パスを使用するPerforceを知っています。 PERFORCEは、クライアントが//Client/C/D
を指している場合、//depot/A/B/
パスもサポートします。ここでは、ローカルファイルシステムにこれらのパスがない可能性があります。
p4 filelog //depot/A/B/C/D
には、ファイルがない場合でも、そのファイルの履歴が表示されます/depot/A/B/C/D
。
p4 filelog C/D
は、適切なディレクトリから実行された場合、そのファイルの履歴も表示します。
リファレンス: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html
リードに続く この回答から 。そして、ページ2-15を Bitsaversからのマニュアル (おかげで @ grawity)。
共有データ
デフォルトで共有するドメイン/ OS分散ファイルシステムの2番目の設計原則は、グローバルな統一ネームスペースを意味します。分散ファイルシステムの名前空間は、巨大なタイムシェアリングファイルシステムの名前空間に似ています。これは、絶対パス名がネットワークルートの名前(//)で始まることができることを除いて、従来のUNIXの階層的な名前空間です。ローカルノードのルート(/ディレクトリ)からの相対パス名を表すこともできます。
また、「最初の印刷:1985年7月」を伴う 古いマニュアルfrom もあります。 1-4ページ:
図1-2の二重スラッシュ(//)は、ネーミングツリーの最上位、ネットワークルートディレクトリを表しています。
したがって、ApolloのDomain/OSが//
ネットワークルート。
ReactOS プロジェクト-これは、NTカーネルと関連するAPIの無料でオープンソースの実装です-独自の Interix -like POSIXサブシステム(MSの元のOS/2サブシステムも コンテキストで言及されています ですが、ReactOSアナログについては言及されていません)。
これまでの取り組みは small でしたが、fork()
は明らかに現実のものです。これは、サブシステムのプロジェクトページからの抜粋で、未解決の問題にリストされています。
パス
POSIXアプリケーションでWin32パスを使用する最良の方法は何ですか?アイデア:
//<device>/<path
>を\\.\<device>\<path>
に変換します(ドライブ文字の特別な場合-//<letter>/<path>
=><letter>:\<path>
-と特別なエスケープ//./<raw text>
=>\\.\<raw text>
。UNCパスは//unc/<path>
)で指定できます。//
パスは、実装固有の動作のために標準で予約されており、Win32パスをエスケープする//<letter>/
構文は、既存のPOSIX互換環境で広く使用されていますそのような「裸の」Win32パスを認識するヒューリスティック
win32パスと
//
パスの大文字と小文字を区別しないルックアップ(この規格では、//
パスのこの種の実装固有の動作を許可していますか?)。
どれだけ実装されているのかわからないので、それがどのように当てはまるのかはわかりませんが、問題の有用な説明であると思いました。
別のアプリケーション: Blender は、先頭の//
をプロジェクトディレクトリ(.blend
ファイルが保存されているディレクトリ)への参照として扱います。 関連するマニュアルページはこちら 。
これは、Unixに似ていないオペレーティングシステム(Windowsなど)にも当てはまります。
漠然とした記憶がある//Host/path
表記法は、AT&T SysV.3で RFS Remote File Sharing 実装の一部として使用されていました。これは、SysV.4がリリースされた頃に廃止され、よりシンプルで人気の高い [〜#〜] nfs [〜#〜] がSun Microsystemsから提供されました。
ただし、構文への具体的な参照は見つかりません。今レビューしたドキュメントでは、ユーザーがリモートホスト名を明示的に指定するという考えは、場所に依存しないという設計原則に反していたようです。
参考資料1. RFSアーキテクチャの概要
1980年代の SEL/Gould にはUTX-32と呼ばれるUnixオペレーティングシステムがあり、//Host/path
はSolarisの/net/Host/path
と同等でした。つまり、リモートアクセスパスpath
on HostHost
。それに関するドキュメントが見つからないので、これがRFSであるのか、並行進化であるのか(またはAT&Tであるのか) ストール Gouldから取得しました)。
POSIXは Rationalefor A.4.12 Pathname Resolution パラグラフ9および10で述べています。
一部のネットワークシステムでは、構成/../hostname/は別のホストのルートディレクトリを参照するために使用され、POSIX.1はこの動作を許可します。
他のネットワークシステムでは、同じ目的で// hostname構成を使用します。つまり、二重の最初のスラッシュが使用されます。
これはseemsで、//
が「ネットワークルート」を意味することを確認するためのものです。少なくとも、ルールがPOSIXに含まれている場合は、これがアイデアでした。
//
で始まるパス名のパスの途中にある/
の意味を削除するためのルールに従います。
...先行しない2つ以上の<slash>文字のシーケンスなので
単一の<スラッシュ>として扱われます...
もちろん、//
で開始されたパス名は、(最初ではなく)パス名内の//
の使用を拡張または変更する場合があります。 POSIX.1ではこれが可能です。これは、許可される//
がパス名の先頭にあることを最後に確認します。