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