TIL: Some surprising code execution sources in bash
-
TIL: Some surprising code execution sources in bash
-
Kees Cook :tux:replied to yossarian (1.3.6.1.4.1.55738) last edited by
@yossarian The use of '[[' is the problem. That's an evaluating comparison and is as dangerous as 'eval' (as shown). All scripts should be using just the single '['. Using '[[' is for compatibility with ancient shells.
-
@kees @yossarian uh, good to know. I'm pretty sure at some point I've been told (maybe by some linting tool?) that [[ is preferrable to [.
-
@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 @yossarian Yeah this was a common recommendation long ago to "avoid bash-isms" for compatibility. Since then busybox and dash (the common non-bash "/bin/sh" instances) grew '[' support either internally or via /usr/bin/[
-
@kees @yossarian I'm confused, this tells me [[ is the bash'ism, and [ the posix thing: https://mywiki.wooledge.org/BashFAQ/031
-
@hanno @kees @yossarian Yeah [[ is a bashism. For example, with FreeBSD's default sh:
[[ x ]] && echo true
/bin/sh: [[: not found[ via a builtin or /usr/bin/[ has existed as far back as I can see