On Wed, Jan 13, 2021, 8:33 PM Lawrence Velázquez <
vq@xxxxxxxxx> wrote:
> On Jan 13, 2021, at 7:27 PM, Devin Hussey <husseydevin@xxxxxxxxx> wrote:
>
>> On Wed, Jan 13, 2021, 5:28 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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.