bug#6339: url-filename => "/c:/some/file.txt"

[Lennart Borgman <lennart.borgman@gmail.com>]

On Thu, Sep 22, 2011 at 00:21, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Sep 21, 2011 at 22:28, Lars Magne Ingebrigtsen <larsi@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.