Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 24 Sep 2019: > > 2019-09-23 15:39:49 +0000, Austin Group Bug Tracker: > [...] > > On page 2384 line 76271 section 2.13.3, change:<blockquote>3. Specified > > patterns shall be matched against existing filenames and pathnames, as > > appropriate.</blockquote>to:<blockquote>3. If a specified pattern contains > > any '*', '?' or '[' characters that will be treated as special (see [xref > > to 2.13.1]), it shall be matched against existing filenames and pathnames, > > as appropriate.</blockquote> > > On page 2384 line 76295 section 2.13.3, add:<blockquote>4. If a specified > > pattern does not contain any '*', '?' or '[' characters that will be > > treated as special, the pattern string shall be left > > unchanged.</blockquote> > [...] > > Thanks for looking into that. > > Does the above mean that > > var='\*' IFS= > printf "%s\n" $var > > is required to output \* regardless of whether a * or \foo file > exists in the current directory exists or not (or whether > nullglob is enabled after bugid:247 resolution)? > > (and we'd need var='[*]' for a glob that matches a * file).
Yes. > If not, and if that \* is meant to match on a * file (like for > find -name '\*'), would that be based on whether the "*" file > can be accessed (search permissions to the current directory > needed), or found in the contents of current directory (read > permission needed)? > > Regardless, the above question applies in > > printf '%s\n' */$var > > Or > > printf '%s\n' $var/* Those both have a * that will be treated as special, so matching against existing files is performed. The permission requirements in these two cases are the same as if you had used var=foo. > (where there are variations among the shells that implement that > second meaning of backslash). Do you mean you see variation in those last two cases, or only in the first case, where bash 4 and earlier do what's specified in the bug 1234 resolution but in bash 5, printf "%s\n" $var outputs * when a * file exists? > Also applies to glob(). Looks like we should modify the description of GLOB_NOCHECK. It refers to rule 3 in XCU 2.13.3 but then goes on to describe the behaviour in a way that doesn't (fully) match that rule any more. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
