Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 29 Jul 2019: > > 2019-07-29 10:45:35 +0100, Geoff Clare: > [...] > > I noticed the same problem when I was working on the wording changes > > to glob() as part of the pathname expansion fixes that arose from > > bug 1255, which is why the proposed change in my email on 25th July > > had: > > > > | In glob() change GLOB_ERR from: > > | > > | Cause glob() to return when it encounters a directory that it > > | cannot open or read. Ordinarily, glob() continues to find matches. > > | > > | to: > > | > > | Cause glob() to return when an attempt to open, read or search a > > | directory fails because of an error condition that is related to > > | file system contents. If this flag is not set, glob() shall > > | not treat such conditions as an error, and shall continue to > > | look for matches. > > > > plus similar fixes further down the page. > [...] > > But here I'm saying that the ENOENT/ENOTDIR errors should be > ignored with GLOB_ERR. It can already be implied to some extent > in that if you get those errors then it's not "directories" > you're trying to open (so it's not a case there "it encounters a > *directory* that it cannot open or read), but still the Solaris > implementation (for both ENOENT and ENOTDIR) and GNU > implementations (for ENOENT) still return errors.
I think you're interpreting the current text too literally. My reading is that it is trying to describe what happens when glob() attempts to open what it expects to be a directory and gets an error. The Solaris behaviour seems like the right thing to do. If an application calls glob() to expand /etc/passwd/*.c without GLOB_NOCHECK and with GLOB_ERR then I think the application writer would want glob() to indicate that there's a problem with the pattern, not just that there are no matches. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
