A Universal Naming Convention (UNC) path can be used to access network resources and is a null-terminated Unicode character string whose format is as follows:
4.3BSDくらいまでは，namei(カーネル注のパス名解析ルーチン)内で空ストリング("")は カレントディレクトリ("."と同じというのではなく，カーネル中のカレントディレクトリのinodeを指してるポインタ)として解釈されてました．
ls ""
は
ls .
と同じだし，
od -c ""
は
od -c .
と同じ．
a/b//c///
は
a/b/./c/././.
と同じ結果．
POSIXにもpathname resolutionの冒頭に「There may be multiple pathnames that resolve to the same file.」って書いてあったりします．
複数の連続するスラッシュは1個と同じ，って規定ですね．
誰が原因なのかは知らないが…\\ が \ 互換な Windows (スコア:1)
例えば
c:\WINDOWS\CONFIG\
というディレクトリがあるとする。これを
c:\WINDOWS\\CONFIG\
のように打ってもエラーにならず、
c:\WINDOWS\CONFIG\
と同じ扱いになる。しかしながら、
c:\\WINDOWS\CONFIG\
はエラーになる。もっと腐っていることに、 2.2.1.4 UNC Path [microsoft.com]によると、
fjの教祖様
Re:誰が原因なのかは知らないが…\\ が \ 互換な Windows (スコア:0)
Linuxも // が / 互換のようですけど。まさか教祖様が知らないはずないし。BSDも(少なくともFreeBSDは)同様みたいですね。SysV完全準拠のシステムとかだと違ったりするんでしょうか。
ちなみにMac OS 9以前は : と :: が明らかに違ったはず。
Re:誰が原因なのかは知らないが…\\ が \ 互換な Windows (スコア:1)
Re:誰が原因なのかは知らないが…\\ が \ 互換な Windows (スコア:1)
それは仕様が腐っている。
カレントディレクトリからでも root ディレクトリからでもかまわないが、
いくつかの ディレクトリを経由して、あるオブジェクトに到達する場合、そのパス名記述ルールは一意であるべきだ。つまり、/ → afo → bfo → cfo と手繰る場合に、
/afo/bfo/cfo
/afo//bfo/cfo
のどちらも許容するのは、パス名の一意決定性に反するのでよろしくない。もちろん、
/afo/./bfo/cfo
は OK だが、それは / → afo → . → bfo → cfo のように「別のパス」を手繰っているから。
fjの教祖様
Re:誰が原因なのかは知らないが…\\ が \ 互換な Windows (スコア:1)
ls ""
は
ls .
と同じだし，
od -c ""
は
od -c .
と同じ．
a/b//c/// は a/b/./c/././. と同じ結果．
POSIXにもpathname resolutionの冒頭に「There may be multiple pathnames that resolve to the same file.」って書いてあったりします． 複数の連続するスラッシュは1個と同じ，って規定ですね．
余談ですが，パス名が/で終わる場合のPOSIX/SUSの記述が揺れ動いたので，Solarisやlinuxの挙動がそれに引っ張られて妙なことになってます（した？）．