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 e
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_VE
Chet Ramey wrote:
> In general, if you enable extglob before a function is parsed and leave
> it on when the function is executed, you should be ok.
I'm thinking about this in terms of bash completion functions. Many of
them use extended globs, but they should not force a specific permanent
extglo
Martin von Gagern wrote:
> 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 construct
Greg Wooledge wrote:
> You're using extglobs inside a function, and extglob was enabled
> at the time the function was delcared. The parser parsed them at that
> time, decided that they are extended globs, and therefore that's what
> they are.
Then why don't they work as extended globs if the ext
On Thu, Oct 01, 2009 at 04:17:33PM +0200, Martin von Gagern wrote:
> #!/bin/bash
>
> shopt -s extglob
> f() {
> if [[ $v == a@(a|b|c)c ]]; then
> case $v in
> a@(a|b|c)c)
You're using extglobs inside a function, and extglob wa
