Re: extglobs in case constructs

[Chet Ramey]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/