SC2016

Expressions don't expand in single quotes, use double quotes for that.

Problematic code:

name=World
echo 'Hello $name'   # Outputs Hello $name

Correct code:

name=World
echo "Hello $name"   # Outputs Hello World

Rationale:

ShellCheck found an expansion like $var, $(cmd), or `cmd` in single quotes.

Single quotes express all such expansions. If you want the expression to expand, use double quotes instead.

If switching to double quotes would require excessive escaping of other metacharacters, note that you can mix and match quotes in the same shell word:

dialog --msgbox "Filename $file may not contain any of: "'`&;"\#%$' 10 70

Exceptions

If you know that you want the expression literally without expansion, you can ignore this message:

# We want this to output $PATH without expansion
# shellcheck disable=SC2016
echo 'PATH=$PATH:/usr/local/bin' >> ~/.bashrc

# We also want this variable to expand "$BASH_SOURCE:$LINE..." during an execution trace. 
# shellcheck disable=SC2016
PS4='+$BASH_SOURCE:$LINENO:$FUNCNAME: '

# We want to control which environment variables envsubst replaces
# shellcheck disable=SC2016
envsubst '${SERVICE_HOST}:${SERVICE_PORT}' config.template > config

ShellCheck also does not warn about escaped expansions in double quotes:

echo "PATH=\$PATH:/usr/local/bin" >> ~/.bashrc

This suggestion is primarily meant to help newbies who assume single and double quotes are basically the same, like in Python and JavaScript. It's not at all meant to discourage experienced users from using single quotes in general. If you are well aware of the difference, please do not hesitate to permanently disable this suggestion with disable=SC2016 in your .shellcheckrc.

ShellCheck tries to increase the signal-to-noise ratio of this warning by ignoring certain well known commands that frequently expect literal dollar signs, such as sh and perl. However, there's a long tail of less common commands and flags that also frequently expect $s, and it's not in ShellCheck's scope to try to keep track of them all. When you come across such a command, please ignore the suggestion, either permanently or for that one instance.

Related resources:

• StackOverflow: How do I use variables in single quoted strings?
• BashFAQ: Practices