GNU bug report logs -
#6339
url-filename => "/c:/some/file.txt"
Previous Next
Full log
Message #29 received at 6339 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 22, 2011 at 00:21, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Wed, Sep 21, 2011 at 22:28, Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote:
>
>> If I say:
>>
>> (setq x (url-generic-parse-url "file:///home/larsi/foo.txt"))
>>
>> Then I get
>>
>> (url-filename x)
>> => "/home/larsi/foo.txt"
>>
>> as expected. Would your patch break that?
>
> My patch would return "home/larsi/foo.txt", yes.
>
> But expecting the slash is a "bug" in you expectations, because the
> *filename* (the path, according to the RFCs, see below) of
>
> file:///home/larsi/foo.txt
>
> is not "/home/larsi/foo.txt". The slash is a separator, part of the
> URI syntax, and "home/larsi/foo.txt" is an absolute path. It's easier
> to see it with the full syntax, in things like
>
> file://localhost/home/larsi/foo.txt
>
> for example. The fact that url-filename returns the slash is a bug;
> just one that nobody has fixed or complained about because it makes
> easier to process the path than having to do
>
> (concat "/" (url-filename "file:///mypath"))
Are we not dealing with two different file name syntaxes here that
just happens to look very similar? I.e. the URL file name syntax and
the unix style file name syntax.
url-filename is now returning the file name in unix style. This is, as
you said, practical, but a bit surprising. I suspect there are some
small mixing of those syntaxes elsewhere too. My suggestion would be
to keep them and document them.
> At least, until you have a Windows URI. And no, this is *not* a
> Windows problem or a Windows bug, it's a bug that makes life easier
> for POSIX at the cost of making it uglier for Windows.
Indeed.
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.