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: Eli Zaretskii <eliz <at> gnu.org>
To: monnier <at> iro.umontreal.ca, enometh <at> meer.net
Cc: 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 14:20:45 +0200

Ping! Do we want to do anything about this issue?

> Cc: enometh <at> meer.net, 74208 <at> debbugs.gnu.org
> Date: Sun, 24 Nov 2024 09:19:47 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: enometh <at> meer.net,  74208 <at> debbugs.gnu.org
> > Date: Sat, 23 Nov 2024 22:00:16 -0500
> > 
> > > Ping! How should we make progress with this issue?
> > 
> > I think the core of this bug report is that `shell-command` can fail
> > when `default-directory` is set to a value that doesn't correspond to
> > a local directory.
> > 
> > At least for things like `(shell-command "date")` this is undesirable.
> > 
> > Maybe `call-process` should try to "look for" a valid directory if
> > `default-directory` isn't good enough?
> 
> It already does:
> 
>   Lisp_Object
>   get_current_directory (bool encode)
>   {
>     Lisp_Object curdir = BVAR (current_buffer, directory);
>     Lisp_Object dir = Funhandled_file_name_directory (curdir);
> 
>     /* If the file name handler says that dir is unreachable, use
>        a sensible default. */
>     if (NILP (dir))
>       dir = build_string ("~");
> 
> I guess this case somehow evades the test?
> 
> 
> 
> 

Previous Next

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