Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use double quote to prevent globbing and word splitting SH-2086 bugrisk: major #2689

Closed
philipjonsen opened this issue Sep 22, 2024 · 1 comment

Comments

@philipjonsen
Copy link

Description
Problematic code:

echo $1
for i in $*; do :; done # this one and the next one also apply to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'

Rationale
The first line in the problematic example looks like "print the first argument". In reality, it does a number of things:

Split the first argument by IFS (spaces, tabs and line feeds).
Expand each of the resulting strings as if it were a glob.
Join all the resulting strings with spaces.
Print the result.
The second line looks like "iterate through all arguments". This line is actually shorthand for the following steps:

Join all the arguments by the first character of IFS (space)
Split them by IFS
Expand each of them as globs
Iterate on the resulting list.
The third line skips the joining part.

Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such.

Strictly speaking, only expansions themselves need to be quoted, but for stylistic reasons, entire arguments with multiple variable and literal parts are often quoted as one:

$HOME/$dir/dist/bin/$file        # Unquoted (bad)
"$HOME"/"$dir"/dist/bin/"$file"  # Minimal quoting (good)
"$HOME/$dir/dist/bin/$file"      # Canonical quoting (good)
When quoting composite arguments, make sure to exclude globs and brace expansions, which lose their special meaning in double quotes: "$HOME/$dir/src/*.c" will not expand, but "$HOME/$dir/src"/*.c will.

Note that $( ) starts a new context, and variables in it have to be quoted independently:

e```
cho "This $variable is quoted $(but this $variable is not)"
echo "This $variable is quoted $(and now this "$variable" is too)"
Exceptions
Sometimes you want to split on spaces, like when building a command line:

options="-j 5 -B"
make $options file
Just quoting this doesn't work. Instead, you should have used an array (bash, ksh, zsh):

options=(-j 5 -B) # ksh: set -A options -- -j 5 -B
make "${options[@]}" file
or a function (POSIX):

make_with_flags() { make -j 5 -B "$@"; }

make_with_flags file
To split on spaces but not perform glob expansion, POSIX has a set -f to disable globbing. You can disable word splitting by setting IFS=''.

Similarly, you might want an optional argument:

debug=""
[[ $1 == "--trace-commands" ]] && debug="-x"
bash $debug script

Quoting this doesn't work, since in the default case, "$debug" would expand to one empty argument while $debug would expand into zero arguments. In this case, you can use an array with zero or one elements as outlined above, or you can use an unquoted expansion with an alternate value:

debug=""
[[ $1 == "--trace-commands" ]] && debug="yes"
bash ${debug:+"-x"} script
This is better than an unquoted value because the alternative value can be properly quoted, e.g. wget ${output:+ -o "$output"}.

Here are two common cases where this warning seems unnecessary but may still be beneficial:

cmd <<< $var # Requires quoting on Bash 3 (but not 4+)
: ${var=default} # Should be quoted to avoid DoS when var='/////'



Double quote to prevent globbing and word splitting here: https://github.com/nitro/blob/master/scripts/build-brotli.sh#L5-L5
@joshuacolvin0
Copy link
Member

Linters typically produce a lot of false positive hits, none of this is useful information.

@joshuacolvin0 joshuacolvin0 closed this as not planned Won't fix, can't repro, duplicate, stale Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants