On Wed, Jan 13, 2021, 5:28 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Tue, Jan 12, 2021 at 7:04 PM Devin Hussey <husseydevin@gmail.com>
> wrote:
> >
> > POSIX specifies that when globbing, parent directories only have to be
> > searchable, not readable.
> >
> > +       /* First check for search permission. */
> > +       if (access(fn, X_OK) != 0)
> >             return;
>
> I don't think this is correct.  Even if it is strictly correct per
> POSIX (which would seem strange to me), it should not be applied in
> zsh native mode (see my previous email about setopts).
>
> % mkdir /tmp/adirectory
> % touch /tmp/adirectory/somefile
> % chmod a-x /tmp/adirectory
> % echo /tmp/adirectory/*
> /tmp/adirectory/somefile
> % echo /tmp/adirectory/*(.)
> zsh: no match
>
> Lack of search permission only means that you can't tell what kind of
> file "somefile" is (you can't read its inode data, e.g., stat() it),
> not that you can't see the name itself.
>

This matches the behavior of the "pure" globber, POSIX, and literally every
other shell.

If we made it accept it unconditionally like my original solution, we would
end up with the *opposite* issue, where CASE_GLOB would fail on files where
NO_CASE_GLOB succeeds.

Case insensitivity should not change the output due to file permissions.

> +       /* Then, if we have read permission, try to open the directory. */
> > +       if (access(fn, R_OK) == 0) {
> > +           int dirs = !!q->next;
> > +           DIR *lock = opendir(fn);
>
> The access call here is redundant; opendir(fn) will fail if there is
> not read permission.  Why do you believe the extra test is needed?


opendir(fn) will also fail if the "folder" is a file.

However, you may be right, if the path is a file, the next access() will
definitely fail, so I could remove that and only return if we can't
access(fn, X_OK).

I think the rest is just re-indentation.  Did I miss an "else" clause
> for the R_OK ?
>

Yes it is just reindentation.

There is no else clause, it goes to the next section of the path if the
current directory is unreadable.


> Can you provide a specific test case that shows the difference in
> behavior with and without this patch?


I think I can throw something together, yes.

As far as I can tell, the patch

would only cause globbing to fail in more cases, not succeed where it
> previously did not.
>

No, that is definitely not the case.

opendir() would fail if either R_OK or X_OK was false, causing unreadable
folders to be a false negative.

This is allowing certain combinations where opendir() would fail.

>