GNU bug report logs -
#6339
url-filename => "/c:/some/file.txt"
Previous Next
Full log
View this message in rfc822 format
On Thu, Sep 22, 2011 at 01:46, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
> But unfortunately that might not be the right answer... Take this URL file name:
>
> file:///c:/some/file.txt
>
> On windows that would be "c:/some/file.txt". What would it mean on a
> unix system? I guess it would mean "/c:/some/file.txt", but I am not
> sure. Perhaps that is an invalid file name on unix?
Quite likely, but IMO you're missing the point.
file:///c:/some/file.txt is a URL, i.e., it's a pointer to some
specific file in some specific place (or files with identical path and
name in different hosts, because the URL is missing the HOST part,
defaulting then to localhost). In fact, it is the URL that points to a
file, in some filesystem, with absolute path "c:/some/file.txt".
Whether that file exists, and whether that path makes sense when you
apply it locally to a POSIX system, i.e., whether you can access a
file with that URL, is irrelevant to the fact that "c:/some/file.txt"
is the path of the URL. You're muddling the waters when you insist in
"context" and "local system" and the like, because that affects to the
*use* of the URL, not its syntax. Splitting a URL into pieces
according to the RFC does not depend on where you do it or how do you
intend to use it.
We wouldn't be having this discussion in an alternative world where
the POSIX path separator was still "/", but the good people who wrote
the URI/URL specs had chosen "#" as the field separator in URLs:
file:##HOST#PATH
file:###c:/some/file.txt vs. file:###some/file.txt
No one would try to split that as "#some/file.txt".
Juanma
This bug report was last modified 13 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.