Bash's extended glob operators `!(pat)`, `@(pat)`, `+(pat)`, `*(pat)` and `?(pat)` are off by default. What does each of them match, how do you turn them on, and why can the single line `shopt -s extglob; echo !(*.txt)` still fail with a syntax error?

## What the operators are A plain glob has no alternation and no repetition. Extended globs add both, in five forms, each wrapping a `|`-separated list of sub-patterns: ```bash shopt -s extglob ?(pattern-list) # zero or one occurrence *(pattern-list) # zero or more occurrences +(pattern-list) # one or more occurrences @(pattern-list) # exactly one of the alternatives !(pattern-list) # anything that does NOT match the list ``` The operator character sits immediately before the parenthesis with no space. Sub-patterns may themselves contain ordinary glob metacharacters and may nest. ```bash touch a.txt b.log c.md report1.csv report22.csv echo !(*.txt) # b.log c.md report1.csv report22.csv echo @(*.log|*.md) # b.log c.md echo report+([0-9]).csv # report1.csv report22.csv echo *.@(jpg|jpeg|png) # any of three image extensions ``` `@(a|b)` is the alternation people miss most often: without extglob there is no way to say "either of these two spellings" in a single pattern, and the usual workaround is brace expansion — but braces are pure text generation and produce words whether or not the files exist, which is a different thing entirely. `!(...)` is the operator with the most surprising semantics. It means "this component matches anything **except** what the list matches", and it composes: `!(*.txt|*.md)` excludes both. Because it is still pathname expansion, it also still obeys the leading-dot rule, so `!(*.txt)` will not sweep in `.hidden` unless `dotglob` is set. Watch the interaction with a suffix: `!(*.txt)*` is not "not a .txt file", because the trailing `*` can absorb the extension. ## Why the one-liner fails ```bash $ shopt -s extglob; echo !(*.txt) bash: syntax error near unexpected token `(' ``` Bash reads input a **whole line at a time** and parses it into commands before executing any of them. At parse time extglob is still off, so `!(` is not recognised as the start of an extended pattern and the `(` is an unexpected token. The `shopt` on the left of the semicolon has not run yet — it cannot, because parsing failed first. The same trap has a bigger version. A function body is parsed as one unit when the function is **defined**, so this does not work either: ```bash setup() { shopt -s extglob; } use() { echo !(*.txt); } # parsed now, while extglob is still off ``` And the same applies to any compound command — an `if` block, a `while` loop, a `{ ...; }` group — that both enables the option and uses the syntax. The reliable habit is to put `shopt -s extglob` on its own line at the top of the script, before anything that uses the syntax is read. A useful diagnostic consequence: the failure is a **syntax error**, not a no-match error. If a colleague reports `syntax error near unexpected token '('` from a script that works on their machine, the first thing to check is whether extglob is enabled where the script is being parsed. ## Practical uses and alternatives The strongest everyday use is deleting or copying everything except something: ```bash shopt -s extglob rm -rf -- !(keep-me|also-keep) # remove everything else in this directory cp -- !(*.tmp) staging/ ``` That is far cleaner than the loop-plus-condition alternative, and it is one of the reasons people knowingly choose bash over POSIX sh. But note the cost: extended globs are **bashisms**. They do not exist in dash, so a `#!/bin/sh` script cannot use them; portability tradeoffs of that kind are their own topic. When a script must stay POSIX, the honest alternatives are `find` with `! -name` or a loop that skips names it does not want. Extended globs are also the pattern syntax used by bash's other pattern contexts, so once extglob is on, the operators become available wherever bash matches patterns rather than only in pathname expansion. ## Enabling it without wrecking the caller `shopt` changes shell state that persists for the rest of the script, and for the caller too if your file is sourced. If a library needs extglob only briefly, save and restore: ```bash prev=$(shopt -p extglob) # prints "shopt -u extglob" or "shopt -s extglob" shopt -s extglob # ... use the patterns ... eval "$prev" ``` Because of the parse-time rule this only works when the code using the pattern is read after the `shopt -s` has executed — in practice, in a separate sourced file or an `eval`'d string. For a normal standalone script, one `shopt -s extglob` near the shebang is simpler and entirely adequate.