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.
* Adds a shell script with functions to install multi-architecture docker
support, as well as build, deploy, and test the shellcheck docker images for
the same set of architectures for which binaries were already built and
deployed as tarballs.
* Hooks up the multi-architecture docker build, deploy, and test to the existing
Travis CI/CD pipeline. It is organized as a separate stage which only runs if
all previous steps in the already existing test stage succeed.
Fixing the following Travis build config validation warnings:
* root: deprecated key sudo (The key `sudo` has no effect anymore.)
* root: missing os, using the default linux
* deploy: key local-dir is not underscored, using local_dir
* language: value sh is an alias for shell, using shell
* root: key matrix is an alias for jobs, using jobs
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.
Vidar Holen
Benjamin Gordon
Furkan Pham
Joseph C. Sible
Marcin Szydelski
Artur Klauser
Gandalf-