SC2154/check-unassigned-uppercase does not report error for $1,...

[kkmuffme]

For bugs

• Rule Id: SC2154/check-unassigned-uppercase
• My shellcheck version: 0.10.0
• The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• 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

• https://www.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
if [[ -n "$4" ]]
then
    echo "$5"
fi

Here's what shellcheck currently says:

No error

Here's what I wanted or expected to see:

5 is referenced but not assigned

The global variables $1, $2,... (not $0) should be checked like any other uppercase variable when check-unassigned-uppercase is used.
The numbers are easily fatfingered and this is an easy mistake to make when restructuring code too.

[wileyhy]

Usually, positional parameters at the global scope are neither declared nor assigned. They may be assigned with: ~ $ set -- x yz If a script writer plans for $4 to only ever be '--dir', and for $5 to be defined if and only if $4 exists, then that would be some valid code there, no? Wiley

…

On Sun, Nov 10, 2024, 20:23 kkmuffme ***@***.***> wrote: For bugs - Rule Id: SC2154/check-unassigned-uppercase - My shellcheck version: 0.10.0 - The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086) - 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 - https://www.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/bashif [[ -n "$4" ]]then echo "$5"fi Here's what shellcheck currently says: No error Here's what I wanted or expected to see: 5 is referenced but not assigned The global variables $1, $2,... (not $0) should be checked like any other uppercase variable when check-unassigned-uppercase is used. The numbers are easily fatfingered and this is an easy mistake to make when restructuring code too. — Reply to this email directly, view it on GitHub <#3080>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUF2F23RWRM4RPIMWW4S6IL2AAWKJAVCNFSM6AAAAABRQ7NJUSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY2DQMBZGUYDGMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kkmuffme]

I think we are talking about quite different use cases. From what I come across, the most common case is bash foo.sh a b c d

[wileyhy]

Well, maybe shellcheck could do something about that, I don't know. Haskell's a undiscovered country if you ask me. I always assumed shellcheck wasn't able to check for assignment of global positional parameters (which are assigned on the command line) because, as a _static_ linter, there isn't any way for it to know the content of _runtime_ data. ? I can offer some workarounds, though. You might already be aware of these. A. "${1:-}" for silencing nounset. (The ':=' parameter expansion cannot be used for assigning values to positional parameters.) B. As a part of a battery of use tests: $ bash -u ./script.sh a b c C. Using `set -u` as part of some debugging procedures. D. "${2:?some error msg}" to check for null or unset variables. Wiley

[kkmuffme]

Thanks, I know, but I have tons of legacy scripts.

There is actually a very simple fool's workaround I used: preprocess the script by replacing all (\$\{?)(\d) with \1sc_global_fake\2 since then those are just "regular" variables and shellcheck reports an error on them.

Therefore, I guess this would be easy enough to fix in shellcheck directly?