SC2086 - False positive in multi-line quoted string

gstory20 commented 2 months ago

For bugs

Rule Id (if any, e.g. SC1000):
My shellcheck version (shellcheck --version or "online"):
[yes] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
[ yes] I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

For new checks and feature suggestions

[n/a] https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
[yes] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

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


#!/bin/bash
help="
Usage:  FREQ [-e] [-d DAY] [-s STEP] [-f FILE]
   or:  FREQ status

where FREQ is daily, nightly, weekly, monthly, or quarterly

-e means edit the file

DAY is Mon, Tue, Wed, Thu, Fri, Sat, or Sun
(default is today's day of the week)

STEP is the 0-based step number
(default is where ever we left off or 0 for new day)

FILE is the file to execute
(default is $HOME/gs/dat/daily/FREQ-HOSTNAME.dat)
(e.g.       $HOME/gs/dat/daily/$(basename $0)-$HOSTNAME.dat)

"
echo "$help"

Here's what shellcheck currently says:

In temp.sh line 18:
(e.g.       $HOME/gs/dat/daily/$(basename $0)-$HOSTNAME.dat)
                                          ^-- SC2086: Double quote to prevent globbing and word splitting.

Did you mean: 
(e.g.       $HOME/gs/dat/daily/$(basename "$0")-$HOSTNAME.dat)

For more information:
  https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...

Here's what I wanted or expected to see:

gstory20 commented 2 months ago

Forgot to include: I saw this in version 0.7.1 and verified it in the current online version.

brother commented 2 months ago

I would probably use a heredoc for that type of string.

The inside of the subshell $(...) will need proper quoting as shellcheck has pointed out. If you had used single quotes for the string the subshell would not execute but I think you wanted the variable $HOME to be expanded and thus that would have crippled that part. Maybe it can be constructed safe with printf. I would opt to add the quotes in the subshell execution at least.

wileyhy commented 2 months ago

In some quarters, there's a common refrain: QEFE: "Quote Every F@#$_&- Expansion." That would apply in most cases, unless you're intending to make use of Word Splitting, using a pattern or regexp on the right hand side of a [[ keyword, for style reasons, on variables known to be integers, on the RHS of a foo=$(echo "$bar") -style parameter assignment, and probably a few other places that escape me at the moment. More frequent use of quotes tends to cause fewer errors than less frequent, basically.

Wiley

On Sun, Sep 1, 2024, 11:42 PM brother @.***> wrote:

I would probably use a heredoc for that type of string.

The inside of the subshell $(...) will need proper quoting as shellcheck has pointed out. If you had used single quotes for the string the subshell would not execute but I think you wanted the variable @HOME to be expanded and thus that would have criippled that part. Maybe it can be constructed safe with printf. I would opt to add the quotes in the subshell execution at least.

— Reply to this email directly, view it on GitHub https://github.com/koalaman/shellcheck/issues/3049#issuecomment-2323931157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUF2F22MP63777CCOEUC2BLZUQCD5AVCNFSM6AAAAABNO5TCW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRTHEZTCMJVG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

koalaman / shellcheck