Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 17 Jun 2019: > > 2019-06-17 15:22:25 +0100, Geoff Clare: > [...] > > > And all other implementations (including all the certified ones, > > > including kre's) should be deemed non-compliant? > > > > Yes. > [...] > > So you would want to sacrifice backward compatibility, break > common usage patterns, force all implementations to be changed > to implement a feature that was probably added by accident to > the standard, that is documented in none of the shells that > implement (part of) it (even bash doesn't document that wildcard > quoting operator), for a feature that was never needed, probably > never asked for and hardly anybody is aware of and can only be > used in corner cases (patterns stored in variables, used > unquoted)?
There's no need to be so melodramatic. You are overstating the consequences of shells changing to become conforming. They are really quite minor, and mostly only affect badly written shell scripts where the author forgot to quote something. The likelihood of breaking a script that intentionally relies on current (except bash5) shell behaviour, i.e. has a backslash in a filename pattern in a shell variable that is expected to match an actual backslash in a filename, is extremely small. Whenever a discrepancy is discovered between the requirements in the standard and existing practice, a decision has to be made as to whether to relax the standard to allow other behaviours, or to uphold the requirements of the standard. The decision is made on a case by case basis, and in this particular case the three ORs supported upholding the standard. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
