Bad Advice

shellcheck doesn't always give the best advice. Here are some examples where you should ignore what shellcheck is saying.

Using printf with dynamic formats:

printf "DEBUG: $fmt${fmt:+\n}" "$@" >&${TERMINAL_STDOUT_PASSTHRU:-1}
       ^-- SC2059: Don't use variables in the printf format string. Use printf "..%s.." "$foo".

It is not always a mistake to use a variable in the format argument of printf. This should be ignored if you are using a dynamic format string.

Using parameter expansion inside the argument space of the : built-in:

: ${TERMINAL_STDOUT_PASSTHRU:=3}
  ^-- SC2086: Double quote to prevent globbing and word splitting.

This should be ignored because shellcheck isn't smart enough to understand that the expansion of the variable is ignored because it appears in the argument space of the : built-in. You do not need to add double-quotes as it suggests.

This same error pops up when you use a variable argument to the return builtin. return only accepts an integer argument and thus it would be of little use to quote the variable when you know it will only ever be a number. The warning about word splitting does not apply in the below situation:

[ "$__name" ] || return $FAILURE
                        ^-- SC2086: Double quote to prevent globbing and word splitting.

Rest assured, any instance of the following will suffer from the same bad advice:

return $SUCCESS
       ^-- SC2086: Double quote to prevent globbing and word splitting.

Using sub-shells in the argument space of the export built-in:

export UNAME_S="$( uname -s )" # Operating System (i.e. FreeBSD)
       ^-- SC2155: Declare and assign separately to avoid masking return values.

What shellcheck refers to as "return value" is actually the "exit status" of the sub-shell where uname -s appears. If you don't care about the error, it should not matter that you put the sub-shell in the argument space of another command.

Using continue inside a loop when inside a function