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

Previous Next

Package: emacs;

Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>

Date: Thu, 3 Jun 2010 02:40:02 UTC

Severity: normal

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Lennart Borgman <lennart.borgman <at> gmail.com>, 6339 <at> debbugs.gnu.org
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 <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"))

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.




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.