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.
References of the form $var and ${var} both map to the same structure in
the AST, which prevents any later analysis functions from distinguishing
them. In preparation for adding checks that need this info, add a Bool
to T_DollarBraced that tracks whether the braces were seen at parsing
time and update all references so that this change is a no-op.
The new json1 format works just like json except that it treats tabs as
single characters instead of 8-character tabstops.
The main use case is to allow editors to pass -fjson1 so that they can
consume the json output in a character-oriented way without breaking
backwards compatibility.
Also addresses #1048.
Add a new optional flag "-r|--root ROOTPATHS", where ROOTPATHS is a
colon separated list of paths, that will look for external sources in
alternate roots.
This is particular useful when the run-time environment does not fully
match the development environment. The #shellcheck source=file directive
is useful, but has its limitations in certain scenarios. Also, in many
cases the directive could be removed from scripts when the root flag is
used.
Script example.bash:
#!/bin/bash
source /etc/foo/config
Example usage where etc/foo/config exists in skel/foo:
# shellcheck -x -r skel/foo:skel/core example.bash
The set builtin accepts certain flags, and some longer synonyms (for
instance set -e is the same as set -o errexit) under POSIX sh. This
makes ShellCheck warn if any of the used flags and options are
undefined when targeting POSIX sh.
This fixes#990, while adding general flag-support checking for set in
the process.
Flags for the hash builtin other than [-r] are undefined under POSIX sh.
Dash also accepts [-v], while bash adds [-l] [-p filename] [-dt] aside
from [-r].
Issue https://github.com/koalaman/shellcheck/issues/1330
Addresses false positives when quoted arguments to echo begin with what
looks like a flag. Now, warn only when the first argument is a
recognized echo flag when flags are unsupported.
The only acceptable flags for the unset builtin under POSIX sh and dash
are [-fv]. Bash though, accepts [-n] too. This commits makes shellcheck
warn about this.