printf "\n${CLEAR_LINE}${RED}💀 Rubocop found some issues. Let's see if it can autocorrect the files you're trying to commit...${NO_COLOR}\n"

Close

Don't use variables in the printf format string. Use printf "..%s.." "$foo".

Problematic code:

printf "Hello, $NAME\n"

Correct code:

printf "Hello, %s\n" "$NAME"

Rationale:

printf interprets escape sequences and format specifiers in the format string. If variables are included, any escape sequences or format specifiers in the data will be interpreted too, when you most likely wanted to treat it as data. Example:

coverage='96%'
printf "Unit test coverage: %s\n" "$coverage"
printf "Unit test coverage: $coverage\n"

The first printf writes Unit test coverage: 96%.

The second writes bash: printf: `\': invalid format character

Exceptions

Sometimes you may actually want to interpret data as a format string, like in:

hexToAscii() { printf "\x$1"; }
hexToAscii 21

or when you have a pattern in a variable:

filepattern="file-%d.jpg"
printf -v filename "$filepattern" "$number"

These are valid use cases with no useful rewrites. Please [[ignore]] the warnings with a [[directive]].

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.

#/bin/bash

Close

Tips depend on target shell and yours is unknown. Add a shebang.

Problematic code:

echo "$RANDOM"   # Does this work?

Correct code:

#!/bin/sh
echo "$RANDOM"  # Unsupported in sh. Produces warning.

or

#!/bin/bash
echo "$RANDOM"  # Supported in bash. No warnings.

Rationale:

Different shells support different features. To give effective advice, ShellCheck needs to know which shell your script is going to run on. You will get a different numbers of warnings about different things depending on your target shell.

ShellCheck normally determines your target shell from the shebang (having e.g. #!/bin/sh as the first line). The shell can also be specified from the CLI with -s, e.g. shellcheck -s sh file.

If you don't specify shebang nor -s, ShellCheck gives this message and proceeds with some default (bash).

Note that this error can not be ignored with a [[directive]]. It is not a suggestion to improve your script, but a warning that ShellCheck lacks information it needs to be helpful.

Exceptions

None. Please either add a shebang or use -s.

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.

  printf "${CLEAR_LINE}🎉${GREEN} Rubocop is appeased.${NO_COLOR}\n"

Close

Don't use variables in the printf format string. Use printf "..%s.." "$foo".

Problematic code:

printf "Hello, $NAME\n"

Correct code:

printf "Hello, %s\n" "$NAME"

Rationale:

printf interprets escape sequences and format specifiers in the format string. If variables are included, any escape sequences or format specifiers in the data will be interpreted too, when you most likely wanted to treat it as data. Example:

coverage='96%'
printf "Unit test coverage: %s\n" "$coverage"
printf "Unit test coverage: $coverage\n"

The first printf writes Unit test coverage: 96%.

The second writes bash: printf: `\': invalid format character

Exceptions

Sometimes you may actually want to interpret data as a format string, like in:

hexToAscii() { printf "\x$1"; }
hexToAscii 21

or when you have a pattern in a variable:

filepattern="file-%d.jpg"
printf -v filename "$filepattern" "$number"

These are valid use cases with no useful rewrites. Please [[ignore]] the warnings with a [[directive]].

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.

source /var/vcap/jobs/cloud_controller_ng/bin/ruby_version.sh

Close

Not following: (error message here)

Reasons include: file not found, no permissions, not included on the command line, not allowing shellcheck to follow files with -x, etc.

Problematic code:

source somefile

Correct code:

# shellcheck disable=SC1091
source somefile

Rationale:

ShellCheck, for whichever reason, is not able to access the source file.

This could be because you did not include it on the command line, did not use shellcheck -x to allow following other files, don't have permissions or a variety of other problems.

Feel free to ignore the error with a [[directive]].

Exceptions:

If you're fine with it, ignore the message with a [[directive]].

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.

if ! cat /etc/hosts | grep "blobstore.service.cf.internal" > /dev/null; then

Close

Useless cat. Consider 'cmd < file | ..' or 'cmd file | ..' instead.

Problematic code:

cat file | tr ' ' _ | nl
cat file | while IFS= read -r i; do echo "${i%?}"; done

Correct code:

< file tr ' ' _ | nl  
while IFS= read -r i; do echo "${i%?}"; done < file

Rationale:

cat is a tool for con"cat"enating files. Reading a single file as input to a program is considered a Useless Use Of Cat (UUOC).

It's more efficient and less roundabout to simply use redirection. This is especially true for programs that can benefit from seekable input, like tail or tar.

Many tools also accept optional filenames, e.g. grep -q foo file instead of cat file | grep -q foo.

Exceptions

Pointing out UUOC is a long standing shell programming tradition, and removing them from a short-lived pipeline in a loop can speed it up by 2x. However, it's not necessarily a good use of time in practice, and rarely affects correctness. [[Ignore]] as you see fit.

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.

  dirs=$(ls -l version | egrep '^d' | awk '{print $9}' | grep -v alpha | sort --version-sort -r)

Close

Use find instead of ls to better handle non-alphanumeric filenames.

Problematic code:

ls -l | grep " $USER " | grep '\.txt$'

Correct code:

find . -maxdepth 1 -name '*.txt' -user "$USER"

Rationale:

ls is only intended for human consumption: it has a loose, non-standard format and may "clean up" filenames to make output easier to read.

Here's an example:

$ ls -l
total 0
-rw-r----- 1 me me 0 Feb  5 20:11 foo?bar
-rw-r----- 1 me me 0 Feb  5  2011 foo?bar
-rw-r----- 1 me me 0 Feb  5 20:11 foo?bar

It shows three seemingly identical filenames, and did you spot the time format change? How it formats and what it redacts can differ between locale settings, ls version, and whether output is a tty.

ls can usually be substituted for find if it's the filenames you're after.

If trying to parse out any other fields, first see whether stat (GNU, OS X, FreeBSD) or find -printf (GNU) can give you the data you want directly.

Exceptions:

If the information is intended for the user and not for processing (ls -l ~/dir | nl; echo "Ok to delete these files?") you can ignore this error with a [[directive]].

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.

trap "pkill -P $$" EXIT

Close

Use single quotes, otherwise this expands now rather than when signalled.

Problematic code:

trap "echo \"Finished on $(date)\"" EXIT

Correct code:

trap 'echo "Finished on $(date)"' EXIT

Rationale:

With double quotes, all parameter and command expansions will expand when the trap is defined rather than when it's executed.

In the example, the message will contain the date on which the trap was declared, and not the date on which the script exits.

Using single quotes will prevent expansion at declaration time, and save it for execution time.

Exceptions

If you don't care that the trap code is expanded early because the commands/variables won't change during execution of the script, or because you want to use the current and not the future values, then you can ignore this message.

Notice

Original content from the ShellCheck https://github.com/koalaman/shellcheck/wiki.