On 09/02/2016 09:04 AM, Herbert Xu wrote:
>> Yes, this looks like a bug in dash. With the default --disable-fnmatch
>> code, when dash encounters [ in a pattern, it immediately treats the
>> following characters as part of the set. If it then encounters the end
>> of the pattern without having seen a matching ], it attempts to reset
>> the state and continue as if [ was treated as a literal character right
>> from the start.
>
> POSIX says:
>
> 9.3.3 BRE Special Characters
>
> A BRE special character has special properties in certain contexts.
...
> An
> expression containing a '[' that is not preceded by a backslash
> and is not part of a bracket expression produces undefined results.
Ah, but POSIX also says:
2.13.1 Patterns Matching a Single Character
[
If an open bracket introduces a bracket expression as in XBD RE
Bracket Expression, except that the <exclamation-mark> character ( '!' )
shall replace the <circumflex> character ( '^' ) in its role in a
non-matching list in the regular expression notation, it shall introduce
a pattern bracket expression. A bracket expression starting with an
unquoted <circumflex> character produces unspecified results. Otherwise,
'[' shall match the character itself.
So while a lone '[' is unspecified in a normal BRE, it is well-defined
in a shell filename pattern matching context. Since '[' is not a
bracket expression, it MUST be treated as a literal '[', so ${foo#[}
MUST strip the leading [ from the contents of foo, without requiring
that the [ be quoted.
>
>> This also affects
>>
>> case [a in [?) echo ok ;; *) echo bad ;; esac
>>
>> which should print ok.
>
> Even ksh prints bad here.
So ksh is also buggy.
>
> I would however consider a patch that simplifies the code in the
> undefined case.
Except that it is well-defined by POSIX, not undefined.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
