On 25/06/2019 08:30, Stephane Chazelas wrote:
2019-06-24 21:56:48 +0100, Harald van Dijk:
On 24/06/2019 21:15, Stephane Chazelas wrote:
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).
I do not see how it makes ksh93 non-compliant. Any use of this violates
2.13.1's "The shell special characters always require quoting.", which is a
requirement on applications. As such, shells are free to interpret it in
whatever way they wish, and consideration should be given to this extension
when coming up with new wording for POSIX.
[...]
That's not what it means. If it did, that would mean things
like:
text='foo bar'
echo $text
would be unspecified because of that "unquoted special
character" (space) after expansion (and unquoted $ before
expansion). Same for:
IFS='|'
text='foo|bar'
for i in $text; do...
All of these are fine, since it is about shell special characters during
pattern matching. All the special characters in your examples are
removed before pattern matching starts.
"special character" is also not defined (or in the "Definitions"
chapter refers to something different). * and ? are also
refered to as special characters later on in the spec.
True, it should be defined, but the rationale makes it clear that
parentheses are considered to be shell special characters in the context
of pattern matching. See xrat/V4_xcu_chap02.html:
To find a filename that contained shell special characters or pattern
characters, both quoting and escaping are required, such as:
pax -r ... "*a\(\?"
to extract a filename ending with "a(?".
There is nothing that makes an exception for unquoted characters coming
from expansions, and there should not be.
Cheers,
Harald van Dijk
