Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 25 Jun 2019:
> That text was probably only to accomodate ast-open/ksh, and it
> again overlooked the case of globs in word expansions. We
> should be able to limit the damage to ( and \ when not inside
> bracket expressions
Here's an attempt at fixing this issue along the lines you suggest,
limiting the damage as much as possible by specifying the patterns
involving '(' that can be treated as special.
On page 2382 line 76216 section 2.13.1 change:
An ordinary character is a pattern that shall match itself. It
can be any character in the supported character set except for
NUL, those special shell characters in [xref to 2.2] that require
quoting, and the following three special pattern characters.
Matching shall be based on the bit pattern used for encoding the
character, not on the graphic representation of the character. If
any character (ordinary, shell special, or pattern special) is
quoted, that pattern shall match the character itself. The shell
special characters always require quoting.
to:
An ordinary character is a pattern that shall match itself. Where
characters within the pattern are affected by shell quoting, an
ordinary character can be any character in the supported character
set except for NUL, those special shell characters in [xref to 2.2]
that require quoting, and characters used in the special patterns
described below. Where characters within the pattern are not
affected by shell quoting, an ordinary character can be any character
in the supported character set except for NUL and characters used in
the special patterns described below. Matching shall be based on
the bit pattern used for encoding the character, not on the graphic
representation of the character. If any character (ordinary, shell
special, or pattern special) is quoted, using either shell quoting
or (where shell quoting is not in effect) a <backslash> escape, that
pattern shall match the character itself. The application shall
ensure that it quotes any character that would otherwise be treated
as special, in order for it to be matched as an ordinary character.
On page 2383 line 76232 section 2.13.1 insert a new paragraph:
Implementations may also treat as a special pattern a sequence of
characters consisting of one of the following, unquoted and not
inside a bracket expression:
* a '?', '*', '+', '@', '!', '%' or '~' character
* the sequence "{n}" where n consists of one or more digits
* the 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.
On page 3748 line 128698 section C.2.13.1 change:
Conforming applications are required to quote or escape the shell
special characters (sometimes called metacharacters). If used
without this protection, syntax errors can result or implementation
extensions can be triggered. For example, the KornShell supports a
series of extensions based on parentheses in patterns.
to:
Where characters within a pattern are affected by shell quoting,
conforming applications are required to quote the shell special
characters (sometimes called metacharacters). If used without this
protection, syntax errors can result or implementation extensions
can be triggered. Historically the Korn Shell supported a series
of extensions based on parentheses in patterns that were valid
extensions because they would otherwise cause syntax errors.
However, this meant that they could not be used in contexts where
those syntax errors would not occur anyway, such as in:
pattern='a*(b)'; ls $pattern
which earlier versions of this standard required to list files
with names beginning 'a' and ending "(b)". This standard now
allows, but does not require, these historical Korn Shell extended
patterns to be recognised in all pattern matching contexts so that
implementations can provide consistency. It is recommended that
implementations do not extend pattern matching in the shell in
ways that are only valid extensions because they would otherwise
be syntax errors, in order to avoid inconsistency between
different pattern matching contexts.
> (and in the case of pathname generation,
> clarify that the presence of \ and ( alone is not enough to
> trigger pathname expansion).
I think it can be worded in a way that makes that obvious without
actually mentioning it explicitly. E.g.:
On page 2384 line 76271 section 2.13.3, change:
3. Specified patterns shall be matched against existing filenames
and pathnames, as appropriate.
to:
3. If a specified pattern contains any '*', '?', '[' or '(' characters
that will be treated as special (see [xref to 2.13.1]), it shall be
matched against existing filenames and pathnames, as appropriate.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
