Allow to declare external variables please

[ale5000-git]

For bugs

• Rule Id (if any, e.g. SC1000):
• My shellcheck version (shellcheck --version or "online"):
• [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

For new checks and feature suggestions

• [x] https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
• [x] 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:

# shellcheck source=/dev/null
. /tmp/other_script.sh

var9="1"
echo "${var1}${var9}"

Here's what shellcheck currently says:

var1 is referenced but not assigned

Here's what I wanted or expected to see:

Sometimes there are variables set in external scripts that cannot be included in the repository. I would like to avoid to disable SC2154 since it apply also to all other cases in the same line.

Could you please allow to declare variables defined externally like this? # shellcheck external_vars=var1,var2,var3,VAR4

[koalaman]

There are some similar suggestions in #356. It may be that listing variables in a directive is ideal.

Alternatives that work today include:

• Explicitly declaring them without assigning: export/declare var1 var2 var3 VAR4
• Putting sample values in a vars.sh and having a # shellcheck source=vars.sh; source /dev/null

(Currently these can also be in dead conditions like false && .. thanks to bad dataflow analysis)

[ale5000-git]

I have an addon.d script for Android that source /tmp/backuptool.functions (script provided by the ROM) so the values of the variables isn't known but it is secure that they are set in the sourced script.

I appreciate the suggestions but export/declare would unnecessarily complicate things and also having an additional vars.sh isn't clean. I think that the most clean thing is declaring them in a comment/directive.

[nepella]

I appreciate the suggestions but export/declare would unnecessarily complicate things . . . .

@ale5000-git: May I ask how? This:

declare var1 var2 var3 VAR4

looks better to me than:

# shellcheck external_vars=var1,var2,var3,VAR4

If the external variables are constant, they can even be made read-only. Or does declare have side-effects?

[ale5000-git]

Because: In POSIX sh, 'declare' is undefined.

I would like one way that doesn't affect code, # is a comment so it doesn't have any side effects. They aren't constant and shouldn't be exported.

[drm]

I would like one way that doesn't affect code, # is a comment so it doesn't have any side effects. They aren't constant and shouldn't be exported.

I agree. I have a very strong intuitive antipathy against "living code" alterations that don't actually improve the code but rather confuse my original intention. Declaring or exporting a variable, in cases like this, aren't at all the responsibility of the sourced script: on the contrary, they are expected to expect the variable to exist, that is the explicit intention of my code. I also do not wish to introduce the ?: expansion, since all my scripts run with set -u already, nor do I wish to introduce default values, because, again, that changes script semantics and would confuse the reader as to what the code intends, which is: to fail if any variable doesn't exist.

So it really is something that involves an instruction to shellcheck (i.e.: "In this case, you needn't worry warning me about this var name", not "In this case, I am ignoring you"). Also, I think it should remove the behavior of ignoring uppercase variable names: it makes a ton more sense to declare these as well. It's after all purely arbitrary who declares these variables...

@koalaman If you would be so kind to give me a few pointers in the right direction, I don't mind looking into an implementation for this.