Should bash syntax checker use extglob by default?

[silenc3r]

Currently linter shows errors on lines containing advanced pattern matching. I think they're quite common in bash scripts and ale should enable extglob by default.

It can be done with:

bash -n -O extglob ...

[rwe]

I agree this makes sense. The following script is correct but completely fails to parse under bash -n because -n the shopt -s extglob isn't executed:

#!/usr/bin/env bash
shopt -s extglob
ls foo.y?(a)ml

Basically if you (or any collaborators) use ALE, you can't use extglob without someone getting confused.

That option is a somewhat special case versus others. As far as I know, no (uncontrived) script that works without extglob will fail with it; but nearly any that use extglob will fail without it. So it seems to be safe to add -O extglob by default when the shell is bash here: https://github.com/dense-analysis/ale/blob/eb864730e2bf843f83dcf58ae43c802ad0cad8ee/ale_linters/sh/shell.vim#L30

Note that extglob is a pretty old option, and supported even by the ancient 3.x bash version on macOS (unlike globstar, which is also common in other places).

[mooreye]

For now, is it possible to somehow add -O extglob in init.vim as a workaround?

[PeterWhittaker]

+1 to at least enabling -O extglob via init.vim or some other mechanism. I'd also be happy with a shellcheck disable, though since this is seen as a hard error and not a warning, I doubt that that would apply.

I really don't like that bright E in code that I know works.