According to POSIX: > The expr utility has a rather difficult syntax [...] In many cases, the arithmetic and string features provided as part of the shell command language are easier to use than their equivalents in expr. Newly written scripts should avoid expr in favor of the new features …
Occurrences
There are 12 occurrences of this issue in the repository.
Variables that are declared but not used for anything should be removed. #### Problematic code: bash foo=42 echo "$FOO" #### Preferred code: bash foo=42 echo "$foo" #### Exceptions: This warning may be falsely emitted when a variable is referenced indirectly, or it is intentionally not used. * Indirection: …
Occurrences
There are 2 occurrences of this issue in the repository.
With double quotes, all parameter and command expansions will expand before trap execution. Using single quotes will prevent expansion at declaration time, and save it for execution time. In the example below, the message will contain the date (and time) on which the line declaring the trap was executed, and …
Occurrences
There are 9 occurrences of this issue in the repository.
Double quotes around $@ (and similarly, ${array[@]}) prevents globbing and word splitting of individual elements, while still expanding to multiple separate arguments. Let's say you have four arguments: baz, foo bar, * and /*/*/*/*. "$@" will expand into exactly that: baz, foo bar, * and /*/*/*/*. $@ will expand into …
Occurrences
There is 1 occurrence of this issue in the repository.
echo won't expand escape sequences. Consider using printf instead: #### Problematic code: bash echo "Name:\t$value" #### Preferred code: bash printf 'Name:\t%s\n' "$value" Backslash escapes like \t and \n are not expanded by echo, and become literal backslash-t, backslash-n. printf does expand these sequences, and should be used instead. …
Occurrences
There are 3 occurrences of this issue in the repository.
Consider using the $(...) notation instead. Backtick command substitution \...`is legacy syntax with several issues. * It has a series of undefined behaviors related to quoting in POSIX. * It imposes a custom escaping mode with surprising results. * It's exceptionally hard to nest.$(...)` command substitution has none …
Occurrences
There are 31 occurrences of this issue in the repository.
$*, unquoted, is subject to word splitting and globbing. Let's say you have three arguments: baz, foo bar and * - "$@" will expand into exactly that: baz, foo bar and * - $* will expand into multiple other arguments: baz, foo, bar, file.txt and otherfile.jpg It is therefore recommended …
Occurrences
There is 1 occurrence of this issue in the repository.
Consider using parameter expansion to search and replace data. In the problematic code the value is passed to sed to do this, but for simple substitutions, parameter expansion can do it with less overhead. #### Problematic code: bash string="stirng" ; echo "$string" | sed -e "s/ir/ri/" #### Preferred code: …
Occurrences
There are 5 occurrences of this issue in the repository.
Problematic code: sh echo $1 for i in $*; do :; done # this one and the next one also apply to expanding arrays. for i in $@; do :; done ## Correct code: ```sh echo "$1" for i in "$@"; do :; done # or, 'for i; …
Occurrences
There are 98 occurrences of this issue in the repository.
When command expansions are unquoted, word splitting and globbing will occur. This can result unintended behaviour filenames contain spaces. Trying to fix it by adding quotes or escapes to the data will not work. Instead, quote the command substitution itself. If the command substitution outputs multiple pieces of data, it …
Occurrences
There are 2 occurrences of this issue in the repository.