New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SC2086 should not complain about usage within set #1194
Comments
You can avoid the warning with.
However while this is safe in your example extra care should be taken to make sure you always control the variables when eval is used. |
I'm not sure this is a general issue with
There are also other reasons why you'd want such a warning:
If splitting/globbing is a generally an issue, but you've identified a specific case where it's not, then that's exactly what disable statements are for. |
I had suggested "Perhaps there could be another warning code for use in set -- specifically.". I'd much prefer just adding a warning specifically to 'set' that I could disable globally compared to in-line disable statements on each use. |
This fixes warnings reported by shellcheck at 0.4.6. The complaints that we are ignoring globally (top of the file) are: 2015: Note that A && B || C is not if-then-else. C may run if A is true. 2039: In POSIX sh, 'local' is undefined. 2162: read without -r will mangle backslashes. 2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined. Most of the complaints were just noise, but a few unused variables were reported and fixed. Related shellcheck issues opened: - koalaman/shellcheck#1191 - koalaman/shellcheck#1192 - koalaman/shellcheck#1193 - koalaman/shellcheck#1194
It seems that SC2086 should not complain about usage with 'set'. In most cases if someone has unquoted strings in
set -- $VAR
then that was by design. Perhaps there could be another warning code for use inset --
specifically.For bugs
For new checks and feature suggestions
Here's a snippet or screenshot that shows the problem:
Here's what shellcheck currently says:
Here's what I wanted or expected to see:
I'd like to not have to disable the check on that line and still get the generally-useful SC2086 globally.
The text was updated successfully, but these errors were encountered: