Re: extglobs in case constructs

[Martin von Gagern]

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
extglob setting on the user. And cleanly restoring the setting can a bit
tricky. I believe I have a solution for this, though:
https://alioth.debian.org/tracker/index.php?func=detail&aid=311628&group_id=100114&atid=413095
Still, that solution brings a bit of overhead, and if that could have
been avoided, I'd been even happier.

> 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.

Still, if there were a way to have the case command remember whether it
was defined with or without extglob, then that state could be recreated
when the command is executed. You'd still have to enable a manual switch
if you wanted to diverge from the Posix standard, only now it would only
have to be when you define the function. The benefit would be that the
semantics of the function would stay unaffected from later modifications
of this shopt.

As an alternative, would you consider things like "local shopts"? I'm
thinking about a flag like "-l" to shopt which would set the option for
the duration of the current function, but neither export it to functions
called therein nor leave it in place when the function returns. I
believe this would be quite a major task, but might be worthwhile for
functions that need to fine-tune these options but don't want to affect
their surroundings. If you are interested, I could try writing a patch.

> 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.

I don't know if I speak for a majority of users, but in my daily use I
prefer bash to be usable intuitively, and consider compatibility to
other shells (which I rarely if ever use) second to that. Things change
if I want to write portable scripts, but in this case, I'd take plain sh
as the common denominator, and would also invoke bash with that name.

So yes, compatibility with other shells is nice, and always having
extended globs as the rhs of an == would increase the ease of use.
Different behaviour for different constructs on the other hand is quite
a bit counterintuitive, and for me personally compatibility with other
shells isn't important enough to warrant this quirk.

Greetings,
 Martin

signature.asc
Description: OpenPGP digital signature