Stephane Chazelas <[email protected]> wrote, on 30 Jul 2019: > > 2019-07-30 10:48:49 +0100, Geoff Clare: > [...] > > The odd thing about all these implementations that ignore ENOTDIR and ENOENT > > (or don't but think they should), is that they are not following either of > > the possible interpretations of the current text. > > > > If they want to interpret it literally and only report an error when they > > encounter an existing directory that they can't open, then they should not > > just ignore ENOTDIR and ENOENT from opendir(), they should also ignore > > ELOOP and ENAMETOOLONG. > [...] > > Note that there's only one implementation (that I found) that > ignores ENOENT: FreeBSD (also found on macOS). ENOTDIR was added > to glibc/gnulib/uclibc/dietlibc because of */*.c returning an > error on non-directory files in the current directory which is a > common, normal case where we don't want an error to be reported. > > While ELOOP and ENAMETOOLONG are pathological case which as you > said in a related discussion could be worth reporting.
No, in the related discussion on pathname expansion I said that those should be treated the same as ENOTDIR and ENOENT because they imply that there can be no matches. > For ENOENT, that can be seen as a pathological case worth > reporting as well, especially in the */*.c case where the > current directory contains broken symlinks. That's inconsistent with your position on ENOTDIR. If regfile exists then you claim regfile/*.c isn't going to produce any matches, so it should be ignored. Likewise if brokensymlink exists then brokensymlink/*.c isn't goint to produce any matches so to be consistent you should also want that to be ignored. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
