Re: url-generic-parse-url with Windows file paths

[Sebastián Monía]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Sebastián Monía <sebastian@sebasmonia.com>
>> I think it should be up to the consumers of url-parse to know how to
>> interpret the filename portion. Going back to the original code, this
>> statement:
>>     (file-exists-p (url-filename parsed))
>> 
>> Should strip the leading / when the path is known to be for a Windows
>> filesystem.
>
> Bu that gets us back to the problem with deciding whether the file
> name is from Windows or from a Posix system.  And file-exists-p is too
> ubiquitous to change what it does now, anyway.

I think I explained myself better in the next email, but I don't suggest
changing file-exists-p. Whoever parses a URL would know better if it's
meant to be a Windows path, and should drop the leading /, before
calling file-exists-p.

> So if url-generic-parse-url cannot solve this problem (and I'm not
> sure it's so, since the chances of "file:///c:/foo" to be a Posix file
> name are extremely slim at best), we need to solve it "by hand" in
> mml-expand-html-into-multipart-related, for example like this:
>
>   (let ((file (url-filename (url-filename parsed))))
>     (or (file-exists-p file)
>         (and (memq system-type '(windows-nt ms-dos))
>            (string-match-p "\\`[/\\][a-z]:[/\\]" file)
>            (file-exists-p (substring file 1)))))

This was my suggestion, whoever uses the output of url-filename is in a
better position to know if it's a Windows or POSIX path.
       
I am curious about your next email and your comment in parenthesis
above. Do you think we should change url-filename to strip the leading /
when we see the pattern "\{a single letter}:"?

Seb

-- 
Sebastián Monía
https://site.sebasmonia.com/