Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 17 Jun 2019: > > 2019-06-17 10:00:50 +0100, Geoff Clare: > > Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 16 Jun 2019: > > > > > > In > > > > > > files='\*x' sh -c 'ls -ld -- $files' > > > > > > We have an unquoted * in that unquoted $files. But here, if it > > > was going to be used as a pattern (by the fnmatch() that would > > > be applied to the list of files in the current directory), the * > > > would end up being quoted by that unquoted \, so the filename > > > generation is not done, a literal \*x is passed to ls. > > > > I think most, if not all, of your examples come down to a conflict > > between two different POSIX requirements. > > Those [1] to [11] points in my previous article identify 11 > differences and exceptions most of which POSIX will have to > specify somehow if they want to allow all existing behaviours in > that regard, or IOW to tell applications what they can do portably.
Once the requirements have had some small clarifications, such as 2.13.1 overriding (actually, "modifying" is probably a better word there) 2.13.3, it should be possible to deduce the required behaviour in your 11 cases. Any shells that deviate from the required behaviour, because they do not treat backslash as special in (parts of) patterns that are not affected by shell quoting, will be deemed non-conforming. If there are any deviations that have a different cause, they could be considered on a case-by-case basis (and if any changes to the standard are needed they should probably be submitted as new bugs). > > In the last paragraph of > > 2.13.1 it says "This escaping <backslash> is discarded". In the last > > paragraph of 2.13.3 it says "If the pattern does not match any existing > > filenames or pathnames, the pattern string shall be left unchanged". > > > > It seems to me that 2.13.1 should be interpreted as overriding 2.13.3, > > as otherwise there would be no point in having that statement there. > > The only place that discarding the backslash makes any difference is > > if the pattern is used for something after the matching operation, and > > the only way for that to happen is when a shell pathname expansion does > > not match any files. But bash sticks to the 2.13.3 requirement and > > uses the pattern unchanged (including the backslash). > > > > In the resolution of bug 1234 we should update 2.13.3 to say > > something like "... left unchanged, except that escaping <backslash> > > pattern characters in parts of the pattern that are not affected by > > shell quoting shall be discarded as specified in [xref to 2.13.1]". > [...] > > I don't think you got my point. > > The question is when filename generation is done at all in that > case you picked up. > > In: > > files='\*x' > printf '%s\n' $files > > bash5 (and for other reasons, shells like ksh93 or dash that > don't treat an unquoted \ as a wildcard quoting operator when > used in pathname expansion) does filename generation, other > shells (zshsh, kresh, bash4) don't. The standard clearly requires pathname expansion to be performed, using the pattern \*x If some shells don't bother to actually read the directory and do any matching operations, depending on the pattern contents, because they know that the outcome will be the same regardless of the contents of the directory, then that's an acceptable internal optimisation, but it doesn't affect what the standard requires the outcome of pathname expansion to be. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
