Bash extglob 的开启位置：函数第一行已经启用，为什么还没调用就报语法错
把扩展模式放进函数，在函数第一行执行 shopt -s extglob，脚本却还没调用函数就报语法错误。原因是 extglob 也会改变解析器怎样理解括号；解析器必须先读完函数定义，之后才可能执行函数体里的开启命令。
下面用两个独立 Bash 子进程分别处理失败与成功版本。保存为 demo.sh，运行 bash --noprofile --norc demo.sh。只匹配内存里的固定字符串，不扫描目录，不修改文件；第一段预期失败，外层显式收集它的状态。
AI模型生成概念示意：先打开解析开关才能通过对应语法关卡，把开关放到关卡后面来不及生效；不是终端截图。
#!/usr/bin/env bash
status=0
bash --noprofile --norc +O extglob -s <<'BAD' 2>/dev/null || status=$?
check_name() {
shopt -s extglob
case $1 in +(ab)) printf 'matched\n';; esac
}
check_name abab
BAD
printf 'enable inside function: status=%s\n' "$status"
[[ $status -eq 2 ]] || exit 1
bash --noprofile --norc +O extglob -s <<'GOOD'
shopt -s extglob
check_name() {
case $1 in
+(ab)) printf '<%s>: match\n' "$1";;
*) printf '<%s>: no match\n' "$1";;
esac
}
check_name ab
check_name abab
check_name aba
check_name ''
GOOD运行时开启，赶不上已经发生的解析
第一行输出 enable inside function: status=2。子进程在读取包含 +(ab) 的 case 分支时失败，尚未执行函数体中的 shopt。示例隐藏了首次诊断文字，只保留退出状态便于核对；删去 2>/dev/null 可以查看 Bash 报出的具体语法位置。
两个子进程启动时都用 +O extglob 明确关闭该选项，避免实验因为继承了已开启的状态而偶然成功。第一段的 || 只负责保存失败状态，不会让那份未成功解析的函数变得可用。检查状态等于二，也能发现实验环境与预期不同的情况。
单独的顶层命令先执行，下一段再读取
第二个子进程把 shopt -s extglob 放在函数定义之前，独占一条顶层命令。它先被读取并执行，随后函数定义才能按新的解析规则读取。四次调用输出 <ab>: match、<abab>: match、<aba>: no match、<>: no match。
+(ab) 表示由 ab 这个模式重复一次或多次组成，因此 ab 和 abab 通过，只有一个不完整尾巴的 aba 不通过，空字符串也不通过。这里使用 case 对整个字符串匹配，结果与目录里有哪些文件没有关系，能把语法问题和文件名展开问题分开观察。
另一种可用入口是在启动命令中加 -O extglob，让解析源码之前就具备这项能力。需要注意正号与减号的区别：示例的 +O 是关闭，-O 才是开启。不要复制失败实验的启动参数后，遗漏后续真正的开启步骤。
包含模式的整段结构都要考虑
同样的时机问题也可能出现在复合命令与命令替换中。把开启语句移到同一对大括号里面、只是文字位置更靠前，并不能证明它会先执行；Bash可能需要先解析整个结构。稳妥做法是让开关在包含扩展模式的结构被读取之前生效。
扩展glob不是正则表达式，符号相像也不代表含义相同。设计校验时要保留正常、重复、残缺和空输入四类样本。本例故意只用短字符串；复杂模式处理长文本时，还需要控制输入规模并评估匹配成本。
资料核对日期：2026年10月2日。完整脚本在 Bash 5.2.37 实跑，退出码与五行标准输出已经逐字核对。
