2019-06-26 15:32:44 +0100, Geoff Clare:
[...]
> Implementations may also treat as a special pattern a sequence of
> characters consisting of one of the following, not inside a bracket
> expression:
>
> * an unquoted '?' or '*' character
>
> * a (quoted or unquoted) '+', '@', '!', '%' or '~' character
>
> * the unquoted sequence "{n}" where n consists of one or more digits
>
> * the unquoted sequence "{m,n}" where m and n consist of zero or more
> digits
>
> immediately followed by an optional unquoted '-', then an unquoted
> '(', then one or more characters that do not include an unquoted ')',
> then an unquoted ')'. The special meaning of any such sequences
> shall be implementation-defined.
That could be interpreted as implying that a sequence that
includes a ( followed by two unquoted ) is required *not* to be
treated specially.
Yet, @(@(x)) is still special in ksh93, and the extended
operator spans up to the second unquoted ), @(@(x) alone is not
valid.
It would be probably be better to simplify it to:
immediately followed by an optional unquoted '-', then an
unquoted '(', then *zero* or more characters then an
unquoted ')'. The special meaning of any such sequences
shall be implementation-defined.
Or just make it unspecified if a pattern has those sequences
without reference to an "extended operator", since it would
otherwise be impossible to fully specify the exact tokenising
rule for them (think of things like ~(P:.*(?:.[^)]+\)|x)).
(also note the "zero" as @() matches the empty string).
Or again, forget all about it and treat the ksh93 behaviour as
non-compliant as is already the case.
--
Stephane
