Showing 270 of 270 total issues
Use $(..) instead of legacy ..
. Open
B2B_VERSION_MINOR=$(( `echo "${MAGENTO_MINOR_VERSION}"` -1 ))
- Read upRead up
- Exclude checks
Use $(STATEMENT) instead of legacy `STATEMENT`
Problematic code
echo "Current time: `date`"
Correct code
echo "Current time: $(date)"
Rationale
Backtick command substitution `STATEMENT`
is legacy syntax with several issues.
- It has a series of undefined behaviors related to quoting in POSIX.
- It imposes a custom escaping mode with surprising results.
- It's exceptionally hard to nest.
$(STATEMENT)
command substitution has none of these problems, and is therefore strongly encouraged.
Exceptions
None.
See also
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Double quote to prevent globbing and word splitting. Open
CMD="${CMD} --search-engine=$searchEngine --elasticsearch-host=$(getESConfigHost $searchEngine) --elasticsearch-port=$(getESConfigPort $searchEngine) --elasticsearch-index-prefix=${DB_NAME}"
- Read upRead up
- Exclude checks
Double quote to prevent globbing and word splitting.
Problematic code:
echo $1
for i in $*; do :; done # this done and the next one also applies to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'
Rationale
The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."
The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one 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:
echo "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"}
.
As always, this warning can be [[ignore]]d on a case-by-case basis.
this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...
FLAGS="-av -e 'ssh -x' --delete --delete-excluded"
...
# shellcheck disable=SC2086
eval rsync $FLAGS ~/dir remote_host:dir
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Double quote to prevent globbing and word splitting. Open
mysql -h $MYSQL_HOST -u $DB_USER --password=$MYSQL_PWD $DB_NAME -e "DELETE FROM store"
- Read upRead up
- Exclude checks
Double quote to prevent globbing and word splitting.
Problematic code:
echo $1
for i in $*; do :; done # this done and the next one also applies to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'
Rationale
The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."
The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one 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:
echo "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"}
.
As always, this warning can be [[ignore]]d on a case-by-case basis.
this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...
FLAGS="-av -e 'ssh -x' --delete --delete-excluded"
...
# shellcheck disable=SC2086
eval rsync $FLAGS ~/dir remote_host:dir
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Double quote to prevent globbing and word splitting. Open
--ignore-table=$DB_NAME.magento_logging_event \
- Read upRead up
- Exclude checks
Double quote to prevent globbing and word splitting.
Problematic code:
echo $1
for i in $*; do :; done # this done and the next one also applies to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'
Rationale
The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."
The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one 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:
echo "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"}
.
As always, this warning can be [[ignore]]d on a case-by-case basis.
this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...
FLAGS="-av -e 'ssh -x' --delete --delete-excluded"
...
# shellcheck disable=SC2086
eval rsync $FLAGS ~/dir remote_host:dir
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Double quote to prevent globbing and word splitting. Open
--ignore-table=$DB_NAME.catalog_product_index_price_opt_agr_idx \
- Read upRead up
- Exclude checks
Double quote to prevent globbing and word splitting.
Problematic code:
echo $1
for i in $*; do :; done # this done and the next one also applies to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'
Rationale
The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."
The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one 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:
echo "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"}
.
As always, this warning can be [[ignore]]d on a case-by-case basis.
this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...
FLAGS="-av -e 'ssh -x' --delete --delete-excluded"
...
# shellcheck disable=SC2086
eval rsync $FLAGS ~/dir remote_host:dir
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
RESTORE_OUTPUT appears unused. Verify it or export it. Open
RESTORE_OUTPUT=$(${BIN_M2INSTALL} -f 2>error.log)
- Read upRead up
- Exclude checks
foo appears unused. Verify it or export it.
Problematic code:
foo=42
echo "$FOO"
Correct code:
foo=42
echo "$foo"
Rationale:
Variables not used for anything are often associated with bugs, so ShellCheck warns about them.
Also note that something like local let foo=42
does not make a let
statement local -- it instead declares an additional local variable named let
.
Exceptions
ShellCheck may not always realize that the variable is in use (especially with indirection), and may not realize you don't care (with throwaway variables or unimplemented features).
For throwaway variables, consider using _
as a dummy:
read _ last _ zip _ _ <<< "$str"
echo "$last, $zip"
or use a directive to disable the warning:
# shellcheck disable=SC2034
read first last email zip lat lng <<< "$str"
echo "$last, $zip"
For indirection, there's not much you can do without rewriting to use arrays or similar:
bar=42 # will always appear unused
foo=bar
echo "${!foo}"
This is expected behavior, and not a bug. There is no good way to statically analyze indirection in shell scripts, just like static C analyzers have a hard time preventing segfaults.
As always, there are ways to [[ignore]] this and other messages if they frequently get in your way.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Use a ( subshell ) to avoid having to cd back. Open
cd -
- Read upRead up
- Exclude checks
Use a ( subshell ) to avoid having to cd back.
Problematic code:
for dir in */
do
cd "$dir"
convert index.png index.jpg
cd ..
done
Correct code:
for dir in */
do
(
cd "$dir" || exit
convert index.png index.jpg
)
done
or
for dir in */
do
cd "$dir" || exit
convert index.png index.jpg
cd ..
done
Rationale:
When doing cd dir; somestuff; cd ..
, cd dir
can fail when permissions are lacking, if the dir was deleted, or if dir
is actually a file.
In this case, somestuff
will run in the wrong directory and cd ..
will take you to an even more wrong directory. In a loop, this will likely cause the next cd
to fail as well, propagating this error and running these commands far away from the intended directories.
Check cd
s exit status and/or use subshells to limit the effects of cd
.
Exceptions
If you set variables you can't use a subshell. In that case, you should definitely check the exit status of cd
, which will also silence this suggestion.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
CURRENT_DIR_NAME appears unused. Verify it or export it. Open
CURRENT_DIR_NAME=$(basename "$(pwd)")
- Read upRead up
- Exclude checks
foo appears unused. Verify it or export it.
Problematic code:
foo=42
echo "$FOO"
Correct code:
foo=42
echo "$foo"
Rationale:
Variables not used for anything are often associated with bugs, so ShellCheck warns about them.
Also note that something like local let foo=42
does not make a let
statement local -- it instead declares an additional local variable named let
.
Exceptions
ShellCheck may not always realize that the variable is in use (especially with indirection), and may not realize you don't care (with throwaway variables or unimplemented features).
For throwaway variables, consider using _
as a dummy:
read _ last _ zip _ _ <<< "$str"
echo "$last, $zip"
or use a directive to disable the warning:
# shellcheck disable=SC2034
read first last email zip lat lng <<< "$str"
echo "$last, $zip"
For indirection, there's not much you can do without rewriting to use arrays or similar:
bar=42 # will always appear unused
foo=bar
echo "${!foo}"
This is expected behavior, and not a bug. There is no good way to statically analyze indirection in shell scripts, just like static C analyzers have a hard time preventing segfaults.
As always, there are ways to [[ignore]] this and other messages if they frequently get in your way.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Declare and assign separately to avoid masking return values. Open
local csvFile="$(getCsvLogFile)"
- Read upRead up
- Exclude checks
Declare and assign separately to avoid masking return values.
Problematic code:
export foo="$(mycmd)"
Correct code:
foo=$(mycmd)
export foo
Rationale:
In the original code, the return value of mycmd
is ignored, and export
will instead always return true. This may prevent conditionals, set -e
and traps from working correctly.
When first marked for export and assigned separately, the return value of the assignment will be that of mycmd
. This avoids the problem.
Exceptions:
If you intend to ignore the return value of an assignment, you can either ignore this warning or use
foo=$(mycmd) || true
export foo
Shellcheck does not warn about export foo=bar
because bar
is a literal and not a command substitution with an independent return value. It also does not warn about local -r foo=$(cmd)
, where declaration and assignment must be in the same command.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Argument to -z is always false due to literal strings. Open
if [ -z getCodeDumpFilename ]
- Read upRead up
- Exclude checks
Argument to implicit -n is always true due to literal strings.
Problematic code:
if [ "$foo " ]
then
echo "this is always true"
fi
Correct code:
if [ "$foo" ]
then
echo "correctly checks value"
fi
Rationale:
Since [ str ]
checks that the string is non-empty, the space inside the quotes in the problematic code causes the test to always be true, since a string with a space can not be empty.
Sometimes this is also caused by overquoting an example, e.g. [ "$foo -gt 0" ]
, which is always true for the same reason. The intention here was [ "$foo" -gt 0 ]
.
Exceptions:
None.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Double quote to prevent globbing and word splitting. Open
local dbDumpFileSize="$(wc -c ${dbDumpFilenamePath} | awk '{print $1}')"
- Read upRead up
- Exclude checks
Double quote to prevent globbing and word splitting.
Problematic code:
echo $1
for i in $*; do :; done # this done and the next one also applies to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'
Rationale
The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."
The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one 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:
echo "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"}
.
As always, this warning can be [[ignore]]d on a case-by-case basis.
this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...
FLAGS="-av -e 'ssh -x' --delete --delete-excluded"
...
# shellcheck disable=SC2086
eval rsync $FLAGS ~/dir remote_host:dir
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Declare and assign separately to avoid masking return values. Open
local recursiveconfigs=$( (find "$(pwd)" -maxdepth 1 -name "${CONFIG_NAME}" ;\
- Read upRead up
- Exclude checks
Declare and assign separately to avoid masking return values.
Problematic code:
export foo="$(mycmd)"
Correct code:
foo=$(mycmd)
export foo
Rationale:
In the original code, the return value of mycmd
is ignored, and export
will instead always return true. This may prevent conditionals, set -e
and traps from working correctly.
When first marked for export and assigned separately, the return value of the assignment will be that of mycmd
. This avoids the problem.
Exceptions:
If you intend to ignore the return value of an assignment, you can either ignore this warning or use
foo=$(mycmd) || true
export foo
Shellcheck does not warn about export foo=bar
because bar
is a literal and not a command substitution with an independent return value. It also does not warn about local -r foo=$(cmd)
, where declaration and assignment must be in the same command.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Expressions don't expand in single quotes, use double quotes for that. Open
addToBootstrap 'exec("ps aux | grep -v \" grep\" | grep \"$command\" | tr -s \" \" | cut -d \" \" -f 2", $pids);'
- Read upRead up
- Exclude checks
Expressions don't expand in single quotes, use double quotes for that.
Problematic code:
name=World
echo 'Hello $name'
Correct code:
name=World
echo "Hello $name"
Rationale:
Single quotes prevent expansion of everything, including variables and command substitution.
If you want to use the values of variables and such, use double quotes instead.
Note that if you have other items that needs single quoting, you can use both in a single word:
echo '$1 USD is '"$rate GBP"
Exceptions
If you want $stuff
to be a literal dollar sign followed by the characters "stuff", you can [[ignore]] this message.
ShellCheck tries to be smart about it, and won't warn when this is used with awk, perl and similar, but there are some inherent ambiguities like 'I have $1 in my wallet'
, which could be "one dollar" or "whatever's in the first parameter".
In the particular case of sed
, ShellCheck uses additional heuristics to try to separate cases like 's/$foo/bar/'
(failing to replace the variable $foo
) with from the false positives like '$d'
(delete last line). If you're still triggering these, consider being more generous with your spaces: use $ { s/foo/bar; }
instead of ${s/foo/bar/;}
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Expressions don't expand in single quotes, use double quotes for that. Open
addToBootstrap ' exec("ps aux | grep -v \" grep\" | grep \"$command\" | tr -s \" \" | cut -d \" \" -f 2", $pids);'
- Read upRead up
- Exclude checks
Expressions don't expand in single quotes, use double quotes for that.
Problematic code:
name=World
echo 'Hello $name'
Correct code:
name=World
echo "Hello $name"
Rationale:
Single quotes prevent expansion of everything, including variables and command substitution.
If you want to use the values of variables and such, use double quotes instead.
Note that if you have other items that needs single quoting, you can use both in a single word:
echo '$1 USD is '"$rate GBP"
Exceptions
If you want $stuff
to be a literal dollar sign followed by the characters "stuff", you can [[ignore]] this message.
ShellCheck tries to be smart about it, and won't warn when this is used with awk, perl and similar, but there are some inherent ambiguities like 'I have $1 in my wallet'
, which could be "one dollar" or "whatever's in the first parameter".
In the particular case of sed
, ShellCheck uses additional heuristics to try to separate cases like 's/$foo/bar/'
(failing to replace the variable $foo
) with from the false positives like '$d'
(delete last line). If you're still triggering these, consider being more generous with your spaces: use $ { s/foo/bar; }
instead of ${s/foo/bar/;}
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Arrays implicitly concatenate in [[ ]]. Use a loop (or explicit * instead of @). Open
if [[ "${missingFiles[@]-}" ]]
- Read upRead up
- Exclude checks
Arrays implicitly concatenate in [[ ]]
. Use a loop (or explicit * instead of @).
Problematic code:
ext=png
allowedExt=(jpg bmp png)
[[ "$ext" = "${allowedExt[@]}" ]] && echo "Extension is valid"
Correct code:
ext=png
allowedExt=(jpg bmp png)
for value in "${allowedExt[@]}"
do
[[ "$ext" = "$value" ]] && echo "Extension is valid"
done
Rationale:
Array expansions in [[ .. ]]
will implicitly concatenate into a single string, much like in assignments. The problematic code is equivalent to [ "$ext" = "jpg bmp png" ]
.
Instead, use a for
loop to iterate over values, and apply your condition to each.
Alternatively, if you do want to concatenate all the values in the array into a single string for your test, use "$*"
or "${array[*]}"
to make this explicit.
Exceptions:
None.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Declare and assign separately to avoid masking return values. Open
local currentSearchEngine="$($BIN_PHP bin/magento config:show catalog/search/engine)"
- Read upRead up
- Exclude checks
Declare and assign separately to avoid masking return values.
Problematic code:
export foo="$(mycmd)"
Correct code:
foo=$(mycmd)
export foo
Rationale:
In the original code, the return value of mycmd
is ignored, and export
will instead always return true. This may prevent conditionals, set -e
and traps from working correctly.
When first marked for export and assigned separately, the return value of the assignment will be that of mycmd
. This avoids the problem.
Exceptions:
If you intend to ignore the return value of an assignment, you can either ignore this warning or use
foo=$(mycmd) || true
export foo
Shellcheck does not warn about export foo=bar
because bar
is a literal and not a command substitution with an independent return value. It also does not warn about local -r foo=$(cmd)
, where declaration and assignment must be in the same command.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Double quote to prevent globbing and word splitting. Open
$BIN_PHP bin/magento config:set "catalog/search/${currentSearchEngine}_index_prefix" $DB_NAME
- Read upRead up
- Exclude checks
Double quote to prevent globbing and word splitting.
Problematic code:
echo $1
for i in $*; do :; done # this done and the next one also applies to expanding arrays.
for i in $@; do :; done
Correct code:
echo "$1"
for i in "$@"; do :; done # or, 'for i; do'
Rationale
The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."
The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one 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:
echo "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"}
.
As always, this warning can be [[ignore]]d on a case-by-case basis.
this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...
FLAGS="-av -e 'ssh -x' --delete --delete-excluded"
...
# shellcheck disable=SC2086
eval rsync $FLAGS ~/dir remote_host:dir
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Useless echo? Instead of 'cmd $(echo foo)', just use 'cmd foo'. Open
B2B_VERSION_MINOR=$(( `echo "${MAGENTO_MINOR_VERSION}"` -1 ))
- Read upRead up
- Exclude checks
SC2116 Useless echo? Instead of 'cmd $(echo foo)', just use 'cmd foo'.
Problematic code:
greeting=$(echo "Hello, $name")
# or
tar czf "$(echo "$(date +%F).tar.gz")" *
Correct code:
greeting="Hello, $name"
# or
tar czf "$(date +%F).tar.gz" *
Rationale:
You appear to be using echo
to write a value to stdout, and then using $(..)
or `..`
to capture the value again. This is as pointless as mailing yourself a postcard: you already have what you want, so there's no need to send it on a round trip.
You can just replace $(echo myvalue)
with myvalue
.
Exceptions
Sometimes this pattern is used because of side effect of echo
or expansions. For example, here $(echo ..)
is used to expand a glob.
glob="*.png"
files="$(echo $var)"
The echo
is not useless, but this code is problematic because it concatenates filenames by spaces. This will break filenames containing spaces and other characters later when the list is split again. Better options are:
- Arrays, if supported by the shell:
files=( $glob ); echo "The first file is ${files[0]}"
- Positional parameters when possible:
set -- $glob; echo "The first file is $1"
- Delaying expansion until it's needed:
for file in $glob; do ...
All three methods will let you avoid issues with special characters in filenames.
As another example, here $(echo ..)
is used to expand escape sequences:
unexpanded='var\tvalue'
expanded="$(echo "$var")"
In this case, use printf
instead. It's well defined with regard to escape sequences.
Finally, if you really do want to concatenate a series of elements by a character like space, consider doing it explicitly with for
or printf
(e.g. printf '%s\n' $glob
).
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
isElasticSearchConfigIsAvailable references arguments, but none are ever passed. Open
function isElasticSearchConfigIsAvailable()
- Read upRead up
- Exclude checks
foo references arguments, but none are ever passed.
Problematic code:
sayhello() {
echo "Hello $1"
}
sayhello
./myscript World
just prints "Hello " instead of "Hello World".
Correct code:
sayhello() {
echo "Hello $1"
}
sayhello "$@"
./myscript World
now prints "Hello World".
Rationale:
In a function, $1
and up refers to the function's parameters, not the script's parameters.
If you want to process your script's parameters in a function, you have to explicitly pass them. You can do this with myfunction "$@"
.
Note that "$@"
refers to the current context's positional parameters, so if you call a function from a function, you have to pass in "$@"
to both of them:
first() { second "$@"; }
second() { echo "The first script parameter is: $1"; }
first "$@"
Exceptions
If the parameters are optional and you currently just don't want to use them, you can ignore this message.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
Can't follow non-constant source. Use a directive to specify location. Open
source "$1";
- Read upRead up
- Exclude checks
Can't follow non-constant source. Use a directive to specify location.
Problematic code:
. "$(find_install_dir)/lib.sh"
Correct code:
# shellcheck source=src/lib.sh
. "$(find_install_dir)/lib.sh"
Rationale:
ShellCheck is not able to include sourced files from paths that are determined at runtime. The file will not be read, potentially resulting in warnings about unassigned variables and similar.
Use a [[Directive]] to point shellcheck to a fixed location it can read instead.
Exceptions:
If you don't care that ShellCheck is unable to account for the file, specify # shellcheck source=/dev/null
.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.