2019-06-24 18:45:55 +0100, Harald van Dijk: [...] > FWIW, that is not what ksh implements and it might be an unreasonable > requirement on ksh. From its manpage: > > > Following splitting, each field is scanned for the characters ∗, ?, (, > > and [ unless the -f option has been set. [...] > > Some of ksh's special globbing features do not feature the regular > metacharacters: > > rm -f a b > touch a > echo ~(N)a ~(N)b > > This is supposed to produce 'a'. > > This particular example is already not required to behave in any particular > way for other reasons, but I do not know whether changes to this example > might produce something where an overly strict requirement in POSIX would > prohibit ksh's behaviour. [...]
Yes, that is not relevant because the behaviour for things like echo @(a) is already unspecified. That's why ksh chose that x(...) syntax for those operators, to keep backward compatibility with the Bourne shell. ksh's *(x) is more awkward to type than zsh's x#, but zsh's # is only enabled with an "extendedglob" option, while ksh's one is always enabled as *(x) would be a syntax error in the Bourne shell. But that means that those ksh extended glob operators are not enabled in: pattern='@(x)'; cmd $pattern or case string in $pattern) ... (for the latter, that changed in ksh93 which makes it non-compliant; ksh88, pdksh, mksh are still OK). zsh's (x|y) or *(qualifiers) are enabled without extendedglob, but not when the shglob is enabled (like in sh emulation). bash also implements the ksh88 extended glob operators with the extglob option, which are then enabled regardless of whether the glob is literal or comes from a word expansion. In any case, except for ksh93 which is already non-compliant, I don't think any of those would cause problem for my proposed "intention". -- Stephane
