Use 'cd ... || exit' or 'cd ... || return' in case cd fails. Open
cd ${SANDBOX_PATH}
- Read upRead up
- Exclude checks
Use cd ... || exit in case cd fails.
Problematic code:
cd generated_files
rm -r *.c
func(){
cd foo
do_something
}
Correct code:
cd generated_files || exit
rm -r *.c
# For functions, you may want to use return:
func(){
cd foo || return
do_something
}
Rationale:
cd
can fail for a variety of reasons: misspelled paths, missing directories, missing permissions, broken symlinks and more.
If/when it does, the script will keep going and do all its operations in the wrong directory. This can be messy, especially if the operations involve creating or deleting a lot of files.
To avoid this, make sure you handle the cases when cd
fails. Ways to do this include
-
cd foo || exit
as suggested to just abort immediately -
if cd foo; then echo "Ok"; else echo "Fail"; fi
for custom handling -
<(cd foo && cmd)
as an alternative to<(cd foo || exit; cmd)
in<(..)
,$(..)
or( )
Exceptions:
ShellCheck does not give this warning when cd
is on the left of a ||
or &&
, or the condition of a if
, while
or until
loop. Having a set -e
command anywhere in the script will disable this message, even though it won't necessarily prevent the issue.
If you are accounting for cd
failures in a way shellcheck doesn't realize, you can disable this message with a [[directive]].
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.
ROOT appears unused. Verify it or export it. Open
ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" && 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.
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.
Assigning an array to a string! Assign as array, or use * instead of @ to concatenate. Open
local message="$@"
- Read upRead up
- Exclude checks
Assigning an array to a string! Assign as array, or use * instead of @ to concatenate.
Problematic code:
var=$@
for i in $var; do ..; done
or
set -- Hello World
msg=$@
echo "You said $msg"
Correct code:
var=( "$@" )
for i in "${var[@]}"; do ..; done
or
set -- Hello World
msg=$*
echo "You said $msg"
Rationale:
Arrays and $@
can contain multiple elements. Simple variables contain only one. When assigning multiple elements to one element, the default behavior depends on the shell (bash concatenates with spaces, zsh concatenates with first char of IFS
).
Since doing this usually indicates a bug, ShellCheck warns and asks you to be explicit about what you want.
If you want to assign N elements as N elements, use an array, e.g. myArray=( "$@" )
.
If you want to assign N elements as 1 element by concatenating them, use *
instead of @
, e.g. myVar=${myArray[*]}
(this separates elements with the first character of IFS
, usually space).
The same is true for ${@: -1}
, which results in 0 or 1 elements: var=${*: -1}
assigns the last element or an empty string.
Exceptions
None.
Notice
Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.