Martin von Gagern wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: i686-pc-linux-gnu-gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
> -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
> -DSYS_BASHRC='/etc/bash/bashrc'
> -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
> -DSSH_SOURCE_BASHRC -march=prescott -O2 -ggdb
> uname output: Linux server 2.6.30-gentoo-r5 #1 SMP PREEMPT Tue Aug 18
> 11:26:16 CEST 2009 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel
> GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
>
> Description:
>
> I've found out that extglobs behave differently in different
> constructs. To avoid syntax errors, the always have to be
> enabled at parse time.
> For comparison constructs like ``[[ $v == a@(a|b|c)c ]]'' this
> is enough. For case constructs like ``case $v in a@(a|b|c)c)''
> the extglob shopt has to be set at runtime as well. This is kind
> of inconsistent.
>
> I've read several messages by Chet on the bug-bash mailing list,
> all claiming that the extglob shopt should change the parser
> only. In this case one would expect that setting it at the time
> a function gets defined should be enough, and that it shouldn't
> be necessary when the function gets executed. Case constructs
> inside a function render this assumption invalid.
You've mischaracterized the substance of those messages. The responses
are always to a question about why extglob also has to be enabled when
a function is parsed, instead of just when the function is executed.
The extglob option controls all aspects of extended globbing: it must
be enabled when executing to pass the correct flags to the matching
engine, and it must be enabled when the construct is parsed to turn off
the usual `metacharacter' definitions of parens and `|'.
In general, if you enable extglob before a function is parsed and leave
it on when the function is executed, you should be ok.
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.
In fact, to be perfectly compatible, bash should temporarily enable
extglob when parsing the rhs of `==' and `!=' inside a conditional
command. I will look at doing that for the next version.
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/
