$value in `<<< $value` doesn't need to be quoted

[sgtpep]

For bugs

• Rule Id (if any, e.g. SC1000): SC2034
• My shellcheck version (shellcheck --version or "online"): 0.4.4
• [x] I tried on shellcheck.net and verified that this is still a problem on the latest commit
• [ ] It's not reproducible on shellcheck.net, but I think that's because it's an OS, configuration or encoding issue

For new checks and feature suggestions

• [ ] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
• [ ] 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
var="foo   bar"
cat <<< $var

Here's what shellcheck currently says:

Line 3: cat <<< $var ^-- SC2086: Double quote to prevent globbing and word splitting.

Here's what I wanted or expected to see:

Nothing.

[koalaman]

This is true in Bash 4, but not in Bash 3.

host1$ echo "$BASH_VERSION"; var='foo    bar'; cat <<< $var
4.4.12(1)-release
foo    bar

host2$ echo "$BASH_VERSION"; var='foo    bar'; cat <<< $var
3.2.57(1)-release
foo bar

Though I'm not necessarily saying it shouldn't be fixed.

[vapier]

fwiw, the bash-4.4 man page says:

Here Strings A variant of here documents, the format is: [n]<<<word

The word undergoes brace expansion, tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, and quote removal. Pathname expansion and word splitting are not performed. The result is supplied as a single string, with a newline appended, to the command on its standard input (or file descriptor n if n is specified).

[nepella]

I was curious enough to look through Bash's changelog: the old behavior of expanding the here string is described as a bug and was fixed in bash-4.4-beta.

[Tamaranch]

I think that this should be fixed, because it's quite confusing. Furthermore, scrolling the web quickly, there is no clear answer to the question of whether or not to quote variables in bash here strings. I had to use github search engine in issues of this repository to find the answer above (and I thought to use it because I know shellcheck, obviously).

[MichaIng]

Just found the same. Interestingly in our case SC2086 is not triggered, but only SC2248 is, while the variable is dynamically generated, so can definitely contain magic characters. So either the false positive is fixed for SC2086 but not for SC2248, or it is not correctly detected that the here string variable is not assured to not contain magic characters. It the second is verified to be true, I'll create a new issue about this.

EDIT: After some shellcheck update, also in our case SC2086 is now thrown. So both rules suffer from the same false positive.