Why would I not leave extglob enabled in bash?

Bash

Bash Problem Overview


I just found out about the bash extglob shell option here:- https://stackoverflow.com/questions/216995/how-can-i-use-inverse-or-negative-wildcards-when-pattern-matching-in-a-unix-linu

All the answers that used shopt -s extglob also mentioned shopt -u extglob to turn it off. Why would I want to turn something so useful off? Indeed why isn't it on by default? Presumably it has the potential for giving some nasty surprises. What are they?

Bash Solutions


Solution 1 - Bash

No nasty surprises -- default-off behavior is only there for compatibility with traditional, standards-compliant pattern syntax.


Which is to say: It's possible (albeit unlikely) that someone writing fo+(o).* actually intended the + and the parenthesis to be treated as literal parts of the pattern matched by their code. For bash to interpret this expression in a different manner than what the POSIX sh specification calls for would be to break compatibility, which is right now done by default in very few cases (echo -e with xpg_echo unset being the only one that comes immediately to mind).

This is different from the usual case where bash extensions are extending behavior undefined by the POSIX standard -- cases where a baseline POSIX shell would typically throw an error, but bash instead offers some new and different explicitly documented behavior -- because the need to treat these characters as matching themselves is defined by POSIX.

To quote http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01">the relevant part of the specification, with emphasis added:

> An ordinary character is a pattern that shall match itself. It can be any character in the supported character set except for NUL, those special shell characters in http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_02">Quoting</A> that require quoting, and the following three special pattern characters. Matching shall be based on the bit pattern used for encoding the character, not on the graphic representation of the character. If any character (ordinary, shell special, or pattern special) is quoted, that pattern shall match the character itself. The shell special characters always require quoting. > > When unquoted and outside a bracket expression, the following three characters shall have special meaning in the specification of patterns: > > - ? - A question-mark is a pattern that shall match any character. > - * - An asterisk is a pattern that shall match multiple characters, as described in http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_02">Patterns Matching Multiple Characters. > - [ - The open bracket shall introduce a pattern bracket expression.

Thus, the standard explicitly requires any non-NUL character other than ?, * or [ or those listed elsewhere as requiring quoting to match themselves. Bash's behavior of having extglob off by default allows it to conform with this standard in its default configuration.


However, for your own scripts and your own interactive shell, unless you're making a habit of running code written for POSIX sh with unusual patterns included, enabling extglob is typically worth doing.

Solution 2 - Bash

Being a Kornshell person, I have extglob on in my .bashrc by default because that's the way it is in Kornshell, and I use it a lot.

For example:

$ find !(target) -name "*.xml"

In Kornshell, this is no problem. In BASH, I need to set extglob. I also set lithist and set -o vi. This allows me to use VI commands in using my shell history, and when I hit v, it shows my code as a bunch of lines.

Without lithist set:

for i in *;do;echo "I see $i";done

With listhist set:

for i in *
do
    echo "I see $i"
done

Now, only if BASH had the print statement, I'd be all set.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionhardcode57View Question on Stackoverflow
Solution 1 - BashCharles DuffyView Answer on Stackoverflow
Solution 2 - BashDavid W.View Answer on Stackoverflow