GNU bug report logs - #21931
25.0.50; behaviour of read-directory-name with double slashes

Previous Next

Package: emacs;

Reported by: Nicolas Richard <youngfrog <at> members.fsf.org>

Date: Mon, 16 Nov 2015 06:29:01 UTC

Severity: normal

Found in version 25.0.50

Done: Nicolas Richard <youngfrog <at> members.fsf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Nicolas Richard <youngfrog <at> members.fsf.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#21931: closed (25.0.50; behaviour of read-directory-name with
 double slashes)
Date: Mon, 23 Nov 2015 14:16:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Mon, 23 Nov 2015 15:14:59 +0100
with message-id <86ziy4vm3g.fsf <at> members.fsf.org>
and subject line Re: bug#21931: 25.0.50; behaviour of read-directory-name with double slashes
has caused the debbugs.gnu.org bug report #21931,
regarding 25.0.50; behaviour of read-directory-name with double slashes
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
21931: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21931
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Nicolas Richard <youngfrog <at> members.fsf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; behaviour of read-directory-name with double slashes
Date: Mon, 16 Nov 2015 07:27:51 +0100
After I eval:
(let ((default-directory "/tmp"))
  (list (read-directory-name "foo" "/tmp/src/")
        (read-directory-name "foo" "/tmp/src//")
        (read-directory-name "foo" "src/")
        (read-directory-name "foo" "src//")
        (read-directory-name "foo" "foo//src/")
        (read-directory-name "foo" "foo//src//")))
and hit RET RET RET RET, I get :
("/tmp/src/" "/" "src/" "/" "/src/" "/")

Is this intended ?

We could normalize the directory name via expand-file-name in all cases,
e.g. :

modified   lisp/files.el
@@ -648,8 +648,7 @@ read-directory-name
   (unless dir
     (setq dir default-directory))
   (read-file-name prompt dir (or default-dirname
-				 (if initial (expand-file-name initial dir)
-				   dir))
+				 (expand-file-name (or initial "") dir))
 		  mustmatch initial
 		  'file-directory-p))

but the docstring states "Value is not expanded---you must call
`expand-file-name' yourself." so I guess the behaviour is important (and
I guess e.g. for tramp).

Should read-file-name be fixed or should the callers make sure to not
use double slashes ?

In GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2015-11-14
Repository revision: ed2e7e20ae0945288c98091f308f5460c3453873
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.3 LTS


[Message part 3 (message/rfc822, inline)]
From: Nicolas Richard <youngfrog <at> members.fsf.org>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 21931-done <at> debbugs.gnu.org
Subject: Re: bug#21931: 25.0.50;
 behaviour of read-directory-name with double slashes
Date: Mon, 23 Nov 2015 15:14:59 +0100
John Wiegley writes:
>>>>>> Nicolas Richard <youngfrog <at> members.fsf.org> writes:
>
>> ("/tmp/src/" "/" "src/" "/" "/src/" "/")
>> Is this intended ?
>
> What list were you expecting to see? "//" has always meant "start at root" to
> mean, ignoring whatever comes prior. This is how C-x C-f works, and it means
> you don't have to delete any existing default text in order to begin at root.

Indeed, but when constructing a path via (concat foo "/" bar), it can
happen that the result contains //. If this is then used as arg to
read-directory-name, this leads to an unexpected default.

OTOH (info "(elisp) Directory Names") explicitly says that using concat
for constructing paths in this way is wrong, so I guess that this bug
report is void.

Thanks for looking into it, I close it.

Nico.


This bug report was last modified 9 years and 182 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.