[woodruffw]

> Double quotes never prevent variable expansion. I am not sure what the author is talking about. Shellcheck is correct to not complain. I stopped reading there.

I think it would behoove you to read the rest of the post. The double quotes are not the operative part of example there; they're only there to demonstrate that the code execution doesn't come from splatting or word splitting.

The actual code execution in Case #1 comes from the fact that bash (and other ksh descendants) run arithmetic evaluation on some strings in arithmetic contexts, regardless of their double or single quoting. That evaluation, in turn, can run arbitrary shell commands.

[usr1106]

So -eq triggers evaluation? Sounds like typical bash magic. I would use [ an the problem goes away.

Showing -eq is not the best example, it can just be replaced by = and the problem goes away.

But if you need -gt or similar there is no replacement. So one should stick to [.

If I follow correctly the dangerous combination is [[ and arithmetic comparisons?

[woodruffw]

`-eq` is for arithmetic comparison; `=` is for string comparison. They don't do the same thing, and it's unsound to uniformly replace either with the other.

The dangerous thing here is that an undefined number of contexts exist where Bash treats strings as arithmetic expressions, which can contain arbitrary code despite not being quoted for expansion. `-eq` is just one example of that; others have linked other examples.

(This is all for case #1. With case #2, `[` and `test` are also susceptible so long as their builtin variants are used.)

[usr1106]

Can you give an example where = would be unsuitable for comparison of numbers?

[woodruffw]

Here's a trivial one:

    $ [[ 0xFF -eq 255 ]] ; echo $?
    0

    $ [[ 0xFF = 255 ]] ; echo $?
    1

[usr1106]

Oh, hex. Another bashism. Not sure when I would have needed that in a shell script last time. So in most cases just using [ solves the problem. If you want to use hex from untrusted user input you need to validate the input first. Yes, the bash programmer needs to be aware of many pitfalls. I wasn't, but I would call myself more a bash avoider than a bash programmer. Yes, I use bash for interactive use, talking only about scripting.

[usr1106]

Ok, need to read it again with more time.

Myself I typically don't script in bash. Most of the extras like [[ are not needed, you can do everything in dash. Arrays are the only feature that comes to my mind where bash would be handy.

[casey2]

I can only assume you were down-voted for calling bloat like arrays useful.