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

[Lennart Borgman]

On Thu, Sep 22, 2011 at 00:45, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 00:31, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> 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.
>
> I would expect that an accessor for the filename slot of a struct
> called URL would interpret the struct as a URL, and the "filename" of
> the URL does not start with a slash. Why would I expect that
> url-filename (url-generic-parse-url, in fact) returns anything "unix
> style" specific?
>
>> url-filename is now returning the file name in unix style.
>
> No.
>
>  (url-generic-parse-url "file:///C:/my/file.xt") => [cl-struct-url
> "file" nil nil "" 21 "/C:/my/file.txt" nil nil t nil]
>
> That's not a "file name in unix style", that's a bug, clear and
> simple.

Ah, yes, of course. I thought everyone reading here was clear about that.

> There's no reason why url-generic-parse-url should think that
> a URL is in some kind of "unix style". What if it is a VMS filename?

You are right. I did not mean to imply that the current behaviour is ok.

>> 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.
>
> "Keep them and document them" still means that it does not work for
> Windows or VMS or anything not POSIX-style. And fixing it just for
> these systems means that we keep a bug for POSIX sake and make other
> systems jump around hoops. Ugly, to say the least.

Of course the behaviour must be fixed too. I meant to write that it is
ok that url-filename returns a system-dependent absolute file name
(for local files).