Harald van Dijk <[email protected]> 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. The attempt to reset the state doesn't look right, and
> has been like this since at least the initial Git commit in 2005.
pdksh exhibits the same behaviour:
$ pdksh -c 'foo=[abc]; echo ${foo#[}'
[abc]
$
POSIX says:
9.3.3 BRE Special Characters
A BRE special character has special properties in certain contexts.
Outside those contexts, or when preceded by a backslash, such a
character is a BRE that matches the special character itself. The
BRE special characters and the contexts in which they have their
special meaning are as follows:
.[\
The period, left-bracket, and backslash shall be special except
when used in a bracket expression (see RE Bracket Expression). An
expression containing a '[' that is not preceded by a backslash
and is not part of a bracket expression produces undefined results.
> This also affects
>
> case [a in [?) echo ok ;; *) echo bad ;; esac
>
> which should print ok.
Even ksh prints bad here.
I would however consider a patch that simplifies the code in the
undefined case.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
