GNU bug report logs - #55877
29.0.50; list-directory doesn't allow globbing interactively

Previous Next

Full log

View this message in rfc822 format

From: chad <yandros <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55877 <at> debbugs.gnu.org
Subject: bug#55877: 29.0.50; list-directory doesn't allow globbing interactively
Date: Sat, 11 Jun 2022 12:38:53 -0400

[Message part 1 (text/plain, inline)]

On Sat, Jun 11, 2022 at 7:02 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> chad <yandros <at> gmail.com> writes:
>
> > I thought I saw an error here when list-directory with a directory (not
> file) glob (ex: ~
> > /Project/emacs/*/) is followed by another list-directory, but I think
> the actual issue is
> > that the default directory in the first case is set to something that
> doesn't exist, which
> > messes up call-process in the second invocation of list-directory. The
> error I saw was:
> >[...]
> I'm unable to reproduce this -- if I say `C-x C-d /tmp/*/ RET' it works
> fine for me...
>

Sorry, I was probably unclear, and my earlier hack-around was no good. The
first call to list-directory works fine. It's the followup, issued from the
buffer of the first, that raises the problem, because default-directory in
the buffer of the first call is set to, in your example, /tmp/*/, and
call-process balks when default-directory doesn't exist.  To repeat, from a
fresh emacs -Q:

`C-x C-d /tmp/*/ RET C-x 0 C-x C-d /tmp/ RET'.

I see "insert-directory: Setting current directory: No such file or
directory, /tmp/*/" in *Messages* in emacs -Q. (In practice, with a fresh
emacs -Q, sometimes I also get the same error from comp-run-async-workers,
if it triggers when I'm in that buffer, which was a surprise.)

I suspect this is due to the explicit setting of default-directory at the
end of list-directory:

>    ;; Finishing with-output-to-temp-buffer seems to clobber
default-directory.
>    (with-current-buffer buffer
>       (setq default-directory
>               (if (file-directory-p dirname)
>                   (file-name-as-directory dirname)
>                  (file-name-directory dirname))))

In the above test case, dirname ends up as "/tmp/*/", which falls through
file-directory-p and ends up passed to file-name-directory, which just
returns it unchanged under unix, because of the trailing slash. This is a
mirror to the logic up-function that checks for wildcards
(insert-directory-wildcard-in-dir-p, etc). I considered ways to pass down
that information or recreate it, but I don't (yet?) have a better answer
for what value it should have than "something safe" or "try to munge the
wildcard into an existing directory", which seems terrible. Maybe the right
answer is to not setq default-directory at all unless dirname is
file-directory-p?

Thanks,
~Chad

[Message part 2 (text/html, inline)]

Previous Next

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