Martin von Gagern wrote:
>> The reason that [[ conditional commands don't require extglob to be
>> enabled while they're executed (and case commands do) lies in how the
>> commands are defined to behave. case commands are defined by Posix:
>> the pattern is always a Posix shell pattern, and any extension to that
>> must be enabled manually. The [[ command, which bash picked up from ksh,
>> is defined so that the rhs of `==' is an extended pattern (ksh always
>> uses extended patterns, without requiring a special option). For
>> compatibility, bash forces the rhs of the [[ command's == and !=
>> operators to be matched as an extended pattern when executed.
>
> That's a good explanation, and a valid reason. If you say it's going to
> stay that way, I'll accept that and stop suggesting alternatives.
It is going to stay that way, with a minor change. I will temporarily
enable extglob when parsing the rhs of `==' or `!=' inside a conditional
command.
The argument that behavior should not depend on current values of shell
options but rather on their setting at some arbitrary point in the past
is one I don't find particularly compelling. It seems to me that in this
particular case, users can either enable extglob to obtain the full
benefit of the completion functions or choose to leave it disabled and
deal with the consequences of not providing an environment the completion
function author expected, with accompanying loss in functionality.
Bash-4.1 will also make it easy to default `extglob' to on, settable at
configuration time. This should make a different solution to this issue
possible, even on a per-vendor basis.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
