bug#71078: rgrep accepts wildcard, then throws it away

[Stefan Kangas <stefankangas@gmail.com>]

Dan Jacobson <jidanni@jidanni.org> writes:

> When rgrep asks for the Base directory, and the user gives a wildcard,
> Base directory: /usr/share/doc/exim4*
> it is thrown away, and this instead gets run:
> (rgrep "minimaldns" "* .*" "/usr/share/doc/exim4")
>
> In fact this is a very special case, as there happens to be a directory
> with just that name,
>
> /usr/share/doc:
>   wildcard exim4*
>   drwxr-xr-x 2 4096 04-13 07:09 exim4-daemon-light
>   drwxr-xr-x 3 4096 04-13 07:09 exim4-base
>   drwxr-xr-x 3 4096 04-13 07:09 exim4-config
>   drwxr-xr-x 2 4096 2023-11-07  exim4-doc-info
>   drwxr-xr-x 3 4096 2023-11-07  exim4-doc-html
>   lrwxrwxrwx 1   10 2016-12-08  exim4 -> exim4-base
>
> Normally rgrep won't let the user even proceed if e.g., the user just gave
> Base directory: /usr/share/doc/exi*
> but in the case where there is in fact a directory that matches exim4,
> the "*" gets thrown away!

That's just how this call works:

    (read-directory-name "Base directory: "
                         nil default-directory t)

If I give an input like "/tmp* RET" at the prompt, it returns "/tmp/".

What's confusing to me is this part in the docstring of
`read-directory-name':

    Fourth arg MUSTMATCH non-nil means require existing directory’s name.
    Non-nil and non-t means also require confirmation after completion.

I think "require existing directory’s name" should be clarified to say:
"require the user to input an existing directory's name", if that is
indeed the intention here.

That it removes the "*" character seems to be undocumented, but if
that's the intended behaviour perhaps it should be clarified too.  Hmm.

Eli, Stefan, any thoughts here?

> In fact if we do add the * here,
> (rgrep "minimaldns" "* .*" "/usr/share/doc/exim4*")
> and do ^X^E, we end up searching ~/ !

I think this is expected, and not a bug, due to this part in grep.el:

     (unless (and dir (file-accessible-directory-p dir))
       (setq dir default-directory))

I'd rather it would signal an error in this case, to be honest, because
I'm not sure it makes much sense to make the function this DWIM-y.  It'd
be good to hear what other people think about this also.