SC2016 false positive

[cornfeedhobo]

For bugs

• [x] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• [x] I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

Here's a snippet or screenshot that shows the problem:

I want a log message that surrounds the variable with quotes, but shellcheck complains:

        local msg="${2:-Command '$1' does not exist!}"
                                ^--^ SC2016: Expressions don't expand in single quotes, use double quotes for that.

However, works as expected:

Command 'fake-command' does not exist!

The standard solution to this has been to white list tools, but that won't do the trick here.

[MichaIng]

I just found the same with this line:

echo "curl -sSfL${USERNAME:+ -u '$USERNAME:$PASSWORD'} '$url' 2>&1 > /dev/null | logger -t dietpi-ddns -p 3" >> /var/lib/dietpi/dietpi-ddns/update.sh

Generally inside double quotes outside of command substitutions, single quotes have no effect on variable expansion, which includes all sorts of shell string manipulation in ${var...}.

As fast as you skip the double quotes, which is usually perfectly fine for variable assignment (as word-splitting and globbing is not done when assigning variables or command substitutions to variables), the variable indeed is not expanded:

# test=success
# string=${empty:-ab '$test' cd}
# echo "$string"
ab $test c
# string="${empty:-ab '$test' cd}"
# echo "$string"
ab 'success' cd

Interestingly also some editors get this wrong. E.g. the GitHub web-based editor shows those single-quoted variables in the bluish colour that indicates that they are interpreted literally, which is wrong.

[kevinoid]

This looks like a duplicate of #501?

[MichaIng]

It is, indeed.

[cornfeedhobo]

Looks like it is. Any idea when #501 will get attention?