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. 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]". -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
