When adding a value containing an equals sign to an indexed array, the
left side is treated as an index if it looks like [N]=val and N is
numeric. SC2191 currently warns about anything that looks like key=val
even though non-numeric values of key will never be treated as an index.
This causes spurious warnings for the common pattern of building up
program arguments in an array, such as:
args=(
--dry-run
--in="${my_var}"
--out=/some/path
-f
)
/bin/program "${args[@]}"
Since only numeric expressions can be a valid index for an indexed
array, only emit SC2191 if the left side of a literal string containing
an equals looks numeric. Other more complicated constructs should still
warn because shellcheck doesn't know if they may evaluate to a numeric
result. Associative arrays still warn because a non-numeric left side
is a valid subscript.
SC2247 already warns about translated strings that look like $"(foo)" or
$"{foo}". Since typical use of translated strings is to translate whole
messages, a string like $"foo" is likely to be a similar mistake if foo
is the name of an existing variable. Conversely, a string like
$"foo bar" is potentially meant to be a message id even if foo is a
known variable.
Add a warning for the $"foo" case, but make it separate from the
existing warning so that projects that reuse variable names as their
message ids can separately disable the new warning.
(bash: missing support for 'builtin' keyword)
Now shellcheck looks for the arguments to 'builtin' to determine
read/written variables. A change in the parser makes sure that
assignments are parsed correctly in commands that start with 'builtin'.
The shflags command-line flags library creates variables at runtime
with a few well-defined functions. This causes shellcheck to spit out
lots of warnings about unassigned variables, as well as miss warnings
about unused flag variables.
We can address this with two parts:
1. Pretend that the shflags global variables are predefined like other
shell variables so that shellcheck doesn't expect users to set them.
2. Treat DEFINE_string, DEFINE_int, etc. as new commands that create
variables, similar to the existing read, local, mapfile, etc.
Part 1 can theoretically be addresssed without this by following sourced
files, but that doesn't help if people are otherwise not following
external sources.
The new behavior is on by default, similar to automatic bats test
behavior.
Addresses #1597
Always using braces makes it harder to accidentally change a variable by
pasting other text next to it, but the warning is off by default because
it's definitely a style preference. Omit special and positional
variables from the check because appending additional characters to them
already doesn't change parsing.
