GNU bug report logs - #74208
31.0.50; minibuffer read-file-name-default mutates global value of default-directory incorrectly

Previous Next

Full log

View this message in rfc822 format

From: Madhu <enometh <at> meer.net>
To: 74208 <at> debbugs.gnu.org
Subject: bug#74208: 31.0.50; minibuffer read-file-name-default mutates global value of default-directory incorrectly
Date: Sat, 07 Dec 2024 22:53:57 +0530 (IST)

*  Eli Zaretskii <eliz <at> gnu.org> <8634izk7ky.fsf <at> gnu.org>
Wrote on Sat, 07 Dec 2024 14:20:45 +0200
> Ping! Do we want to do anything about this issue?

is "Keep it open" an option? :)

call-process calls get_current_directory (which you exhibited) which
in turn calls unhandled-file-name-directory, for which the
documentation is

```
"unhandled-file-name-directory"

Return a directly usable directory name somehow associated with \
FILENAME.
A `directly usable' directory name is one that may be used without the
intervention of any file name handler.
If FILENAME is a directly usable file itself, return
\(file-name-as-directory FILENAME).
If FILENAME refers to a file which is not accessible from a local process,
then this should return nil.
The `call-process' and `start-process' functions use this function to
get a current directory to run processes in.
```

(let ((default-directory "https://www.gnu.org/"))
  (unhandled-file-name-directory default-directory))
=> "https://www.gnu.org/"

call-process is bound to fail.

I still haven't gotten around to trying url completions (I use the
implementation in emacs-w3m w3m-urls-completion) but assuming it is
going to useful, perhaps the completion mechanism should work off a
new url-default-directory rather than default-directory if needed.

Previous Next

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