Nevermind, I'm dumb on that last part, I forgot that the shell option
syntax is backwards.

On Wed, Jan 13, 2021, 9:22 PM Devin Hussey <husseydevin@gmail.com> wrote:

>
> On Wed, Jan 13, 2021, 8:33 PM Lawrence Velázquez <vq@larryv.me> wrote:
>
>> > On Jan 13, 2021, at 7:27 PM, Devin Hussey <husseydevin@gmail.com>
>> wrote:
>> >
>> >> On Wed, Jan 13, 2021, 5:28 PM Bart Schaefer <schaefer@brasslantern.com>
>> wrote:
>> >>
>> >> 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.
>>
>> But your patch *does* cause globbing to fail in cases for which it
>> currently doesn't.
>>
>>         % mkdir -p notsearchable/{dir,DIR}
>>         % touch notsearchable/{dir,DIR}/file
>>         % chmod 600 notsearchable
>>         % zsh -fc 'echo notsearchable/*'
>>         notsearchable/DIR notsearchable/dir
>>         % ./zsh-patched -fc 'echo notsearchable/*'
>>         zsh:1: no matches found: notsearchable/*
>>
>
> Huh. Yeah, that is a bug.
>
> I don't yet understand enough of the logic.
>
> > 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.
>>
>> If I'm understanding your intention correctly, you would like
>> "literal" segments (e.g., lacking special characters) of
>> case-insensitive glob patterns to match literally if the "parent"
>> lacks read permissions. This doesn't seem to work, though. Am I
>> missing something?
>>
>
> That is correct.
>
> To reiterate the problem:
>
>  - Case-sensitive (and POSIX) globs seemingly only fail if the parent
> directory is unsearchable or if the target directory is unreadable, as it
> only opens the globbed directory.
>
>  - The case-insensitive ("impure") glob will fail if ANY parent is
> unreadable or unsearchable. This is because unlike the normal glob, the
> impure glob will try to recursively opendir() from "/".
>
>  - If I ignore EACCES entirely like in my first patch, case-insensitive
> globs would succeed if the parent is unsearchable, causing the opposite bug
> where case-sensitive globs fail.
>
>  - The current patch does not handle the target directory being readable
> but not searchable.
>
> I admit that I know very little about the Zsh source tree, so I have
> tunnel vision when it comes to the program logic. It is likely I who is
> missing something obvious.
>
> The only reason that I found the cause of this bug was via strace.
>
>         % mkdir -p notreadable/dir
>>         % touch notreadable/dir/file
>>         % chmod 300 notreadable
>>         % zsh -f +o CASE_GLOB -c 'echo notreadable/dir/*'
>>         zsh:1: no matches found: notreadable/dir/*
>>         % ./zsh-patched -f +o CASE_GLOB -c 'echo notreadable/dir/*'
>>         zsh:1: no matches found: notreadable/dir/*
>
>
> I didn't do anything that would directly affect CASE_GLOB, as CASE_GLOB
> uses the "pure" codepath. It is expected that the behavior would not change.
>