Back

@kees @yossarian Do we need to do something about this?

$ git grep '\[\[.*\]\]' origin/master -- ':*.sh' | wc --lines
1065

edit: there is some amount of false positives from sed regexes embedded in shell scripts. but also enough real cases

@vegard @kees @yossarian more like git grep '\[' ...

at least for me the `oh bummer' part was the observation that [ also behaves this way, because in bash it's a builtin. perhaps that can actually be considered a bug?

@kees @yossarian https://www.shellcheck.net/wiki/SC2292 says "[[ .. ]] suppresses word splitting and globbing, supports a wider variety of tests, and is generally safer and better defined than [ .. ]"
Not enabled by default in current version, but I believe it was in the past.

@hanno @kees huh yeah, I guess that’s where I got the idea that [[ was preferred over [ from! thanks for finding that!

@kees @yossarian I'm confused, this tells me [[ is the bash'ism, and [ the posix thing: https://mywiki.wooledge.org/BashFAQ/031

@hanno @kees yeah, I thought it was the other way around — [[ is always a builtin and [ is the standard test, which is *also* sometimes a builtin (e.g. within bash in some contexts)

@kees @hanno @yossarian `[` is the POSIX one, but it has silly semantics around strings, which is you you end up doing stuff like `[ "x$foo" -ne "x" ]` to test non-emptiness.

`[[` on the other hand behaves "sanely", but it's definitely a bashism and not portable.

@kees @hanno @yossarian There are many misconceptions in this thread. The test command `[` is well-defined[1] and works as expected. It can be argued that `[[` doesn't work as expected since it introduces semantics which are incompatible with the rest of the shell language.

@flameeyes Your example is wrong, `-ne` is for math. You can test for null or unset simply: `[ "$foo" ]`.

Neither option is unsafe, OP issue stems from array indexing in bash, specifically.

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

@yossarian

$ type [
[ is a shell builtin
$ foo='a[$(echo bad >&2)] + 7'
$ if [ "$foo" -eq 0 ]; then echo zero; fi
-bash: [: a[$(echo bad >&2)] + 7: integer expression expected
$ if /usr/bin/[ "$foo" -eq 0 ]; then echo zero; fi
/usr/bin/[: invalid integer ‘a[$(echo bad >&2)] + 7’

Both built-in and binary appear safe to me. The [[ remains unsafe:

$ if [[ "$foo" -eq 0 ]]; then echo zero; fi
bad

@yossarian

Dash and busybox are safe too:

dash: 3: [: Illegal number: a[$(echo bad >&2)] + 7

sh: a[$(echo bad >&2)] + 7: bad number

@kees out of curiosity, which version of bash was that? I got the [ and test variants working locally; I’ll find and share those tonight

@yossarian My bash is from Ubuntu 22.04:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

If you have a PoC working with [ I am excited to see it! I wonder if there is some distro shell patching going on...

@kees @hanno

here's a PoC for `test` and `[` working with the `-v` case:

```
# case 1
test -v 'x[$(cat /etc/passwd)]'

# case 2
[ -v 'x[$(cat /etc/passwd)]' ]
```

OTOH the arithmetic case doesn't work, and i get the same errors as you two:

```
$ test 'a[$(cat /etc/passwd > /tmp/pwned)]' -eq 0
bash: test: a[$(cat /etc/passwd > /tmp/pwned)]: integer expression expected

$ [ 'a[$(cat /etc/passwd > /tmp/pwned)]' -eq 0 ]
bash: [: a[$(cat /etc/passwd > /tmp/pwned)]: integer expression expected
```

...so my post is a little wrong, the "it works for [ and test" should be only under the `-v` case

@kees @hanno

also, that's with `GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)`

@vathpela @yossarian Nah, [ is a builtin too

@kees @yossarian oh this is one of those things where it was different in the past for dumb reasons, isn't it?

@vathpela @kees @yossarian It's mostly that POSIX defines [ to exist as a binary but allows for a shell to instead implement it as a built-in.