Possible misspelling: VAR may not be assigned

ShellCheck noticed a variable that looks like a near-miss of one you defined. Often a typo.

Problem

This rule fires when ShellCheck sees a variable that is one letter or case-change away from one defined elsewhere in the script. Without `set -u` the typo silently expands to empty, producing weird downstream behavior (a missing path, a no-op command, an unauthenticated request).

Bad

DEPLOY_TARGET=prod
deploy "$DEPLOY_TARGT"   # typo — expands to ""

Good

set -u
DEPLOY_TARGET=prod
deploy "$DEPLOY_TARGET"

Explanation

Always run scripts with `set -euo pipefail` so typos abort instead of silently degrading. Add the `# shellcheck disable=SC2153` directive only when the variable genuinely comes from the environment.

Related

SC2154

When It Matters

ShellCheck raises this when a script references an uppercase variable that is never assigned but closely resembles one that is — typically $PATH_NAME where the script sets $PATHNAME, or $HOME_DIR where it sets $HOMEDIR. With set -u the script dies; without it, the reference expands to the empty string and the failure happens further downstream, in a path concatenation or a delete. Because the name looks like a familiar environment variable, reviewers read past it, which is why the heuristic exists at all.

Second Example

Note

The ${VAR:?message} form aborts with a clear error when the variable is empty or unset, which is exactly the guard destructive commands need.

Exceptions

The variable may legitimately come from the environment, a sourced config file, or an export in a wrapper script — ShellCheck cannot see any of those. Declare it in the script with a comment, or add "# shellcheck disable=SC2153" plus a note about where the value originates.

Faq

Q

How do I tell ShellCheck a variable comes from the environment?

A

Reference it once with a default, or add a directive comment. For sourced files, "# shellcheck source=./config.sh" lets ShellCheck follow the file and see the assignments.

Q

Does set -u catch this?

A

Yes, at runtime: an unset variable becomes a fatal error instead of an empty string. It is the single most valuable line you can add to a script that manipulates paths.

Q

Why only uppercase names?

A

The check is a similarity heuristic tuned to environment-style names, where a near-miss is both common and hard to spot by eye.