[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6339: url-filename => "/c:/some/file.txt"
From: |
Juanma Barranquero |
Subject: |
bug#6339: url-filename => "/c:/some/file.txt" |
Date: |
Thu, 22 Sep 2011 00:21:03 +0200 |
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"))
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.
Juanma
>From RFC 1738 "Uniform Resource Locators (URL)"
3.10 FILES
The file URL scheme is used to designate files accessible on a
particular host computer. This scheme, unlike most other URL schemes,
does not designate a resource that is universally accessible over the
Internet.
A file URL takes the form:
file://<host>/<path>
where <host> is the fully qualified domain name of the system on
which the <path> is accessible, and <path> is a hierarchical
directory path of the form <directory>/<directory>/.../<name>.
For example, a VMS file
DISK$USER:[MY.NOTES]NOTE123456.TXT
might become
<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted'.
The file URL scheme is unusual in that it does not specify an
Internet protocol or access method for such files; as such, its
utility in network protocols between hosts is limited.
- bug#6339: url-filename => "/c:/some/file.txt", Lars Magne Ingebrigtsen, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt",
Juanma Barranquero <=
- bug#6339: url-filename => "/c:/some/file.txt", Lennart Borgman, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Lennart Borgman, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Lennart Borgman, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Lennart Borgman, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Lennart Borgman, 2011/09/21
- bug#6339: url-filename => "/c:/some/file.txt", Juanma Barranquero, 2011/09/21