View on GitHub

Line length

[![Build Status](]( [![codecov](]( [![Go Report Card](]( [![Code Climate](]( [![codebeat badge](](
Severity: Info
Found in by markdownlint

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

This redirection doesn't have a command. Move to its command (or use 'true' as no-op).

> coverage.txt
Severity: Minor
Found in by shellcheck

This redirection doesn't have a command. Move to its command (or use 'true' as no-op).

Problematic code:

```sh { echo "Report for $(date +%F)" uptime df -h }

report.txt ```

Correct code:

sh { echo "Report for $(date +%F)" uptime df -h } > report.txt


ShellCheck found a redirection that doesn't actually redirect from/to anything.

This could indicate a bug, such as in the problematic code where an additional linefeed causes report.txt to be truncated instead of containing report output, or in foo & > bar, where either foo &> bar or foo > bar & was intended.

However, it could also be intentionally used to truncate a file or check that it's readable. You can make this more explicit for both ShellCheck and human readers by using true or : as a dummy command, e.g. true > file or : > file.


There are no semantic problems with using > foo over true > foo, so if you don't see this as a potential source of bugs or confusion, you can [[ignore]] it.


Original content from the ShellCheck

Double quote to prevent globbing and word splitting.

  go test -covermode=atomic -coverprofile=profile.out $d
Severity: Minor
Found in by shellcheck

Double quote to prevent globbing and word splitting.

Problematic code:

sh echo $1 for i in $*; do :; done # this done and the next one also applies to expanding arrays. for i in $@; do :; done

Correct code:

sh echo "$1" for i in "$@"; do :; done # or, 'for i; do'


The first code looks like "print the first argument". It's actually "Split the first argument by IFS (spaces, tabs and line feeds). Expand each of them as if it was a glob. Join all the resulting strings and filenames with spaces. Print the result."

The second one looks like "iterate through all arguments". It's actually "join all the arguments by the first character of IFS (space), split them by IFS and expand each of them as globs, and iterate on the resulting list". The third one skips the joining part.

Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such.

Strictly speaking, only expansions themselves need to be quoted, but for stylistic reasons, entire arguments with multiple variable and literal parts are often quoted as one:

sh $HOME/$dir/dist/bin/$file # Unquoted (bad) "$HOME"/"$dir"/dist/bin/"$file" # Minimal quoting (good) "$HOME/$dir/dist/bin/$file" # Canonical quoting (good)

When quoting composite arguments, make sure to exclude globs and brace expansions, which lose their special meaning in double quotes: "$HOME/$dir/src/*.c" will not expand, but "$HOME/$dir/src"/*.c will.

Note that $( ) starts a new context, and variables in it have to be quoted independently:

sh echo "This $variable is quoted $(but this $variable is not)" echo "This $variable is quoted $(and now this "$variable" is too)"


Sometimes you want to split on spaces, like when building a command line:

sh options="-j 5 -B" make $options file

Just quoting this doesn't work. Instead, you should have used an array (bash, ksh, zsh):

bash options=(-j 5 -B) # ksh: set -A options -- -j 5 -B make "${options[@]}" file

or a function (POSIX):

sh make_with_flags() { make -j 5 -B "$@"; } make_with_flags file

To split on spaces but not perform glob expansion, Posix has a set -f to disable globbing. You can disable word splitting by setting IFS=''.

Similarly, you might want an optional argument:

sh debug="" [[ $1 == "--trace-commands" ]] && debug="-x" bash $debug script

Quoting this doesn't work, since in the default case, "$debug" would expand to one empty argument while $debug would expand into zero arguments. In this case, you can use an array with zero or one elements as outlined above, or you can use an unquoted expansion with an alternate value:

sh debug="" [[ $1 == "--trace-commands" ]] && debug="yes" bash ${debug:+"-x"} script

This is better than an unquoted value because the alternative value can be properly quoted, e.g. wget ${output:+ -o "$output"}.

As always, this warning can be [[ignore]]d on a case-by-case basis.

this is especially relevant when BASH many not be available for the array work around. For example, use in eval or in command options where script has total control of the variables...

```sh FLAGS="-av -e 'ssh -x' --delete --delete-excluded" ...

shellcheck disable=SC2086

eval rsync $FLAGS ~/dir remote_host:dir ```


Original content from the ShellCheck