Conditionals

In most languages if evaluates a boolean expression. In the shell, if runs a command and looks at its exit status: 0 means true, anything else means false. Brackets are not part of the if syntax at all; [ is just a command (with ] as its last argument) that happens to be used in conditions a lot.

if COMMANDS; then
  ...
elif COMMANDS; then
  ...
else
  ...
fi

Any command is a condition

Programs that answer yes-or-no questions report it in their exit status: grep -q (found a match?), cmp -s (files identical?), id -u name (user exists?), command -v (program installed?). Use them directly; there is no need to run the command and then inspect $?.

$ if grep -q "TODO" notes.txt; then
>   echo "notes.txt has open items"
> fi
> if ! command -v git >/dev/null; then
>   echo "git is not installed"
> fi
> if cmp -s todo.txt todo.txt; then echo "identical"; fi

notes.txt has open items
git is not installed
identical

The roundabout form cmd; if [ $? -eq 0 ]; then works but is longer, and breaks as soon as someone adds a line between the command and the test. Reserve $? for when you need the specific code, as with grep, which returns 1 for "no match" and 2 for "error".

$ for f in todo.txt notes.txt missing.txt; do
>   grep -q "TODO" "$f" 2>/dev/null
>   case $? in
>     0) echo "$f: has a TODO" ;;
>     1) echo "$f: no TODO" ;;
>     *) echo "$f: could not be read" ;;
>   esac
> done

todo.txt: no TODO
notes.txt: has a TODO
missing.txt: could not be read

Three ways to write a test

[[ ]] is safer than [ ]: variables inside are not word-split or globbed, &&, ||, < and > work as operators rather than shell syntax, and == can match glob patterns, =~ regular expressions. All operators are covered in Test operators.

$ file="file with spaces.txt"; count=12
> if [ -f "$file" ] && [ "$count" -gt 10 ]; then echo "[ ]: yes"; fi
> if [[ -f $file && $count -gt 10 ]]; then echo "[[ ]]: yes"; fi
> if (( count > 10 )); then echo "(( )): yes"; fi
> if [[ $file == *.txt ]]; then echo "pattern match: a .txt file"; fi

[ ]: yes
[[ ]]: yes
(( )): yes
pattern match: a .txt file

elif and else

Chains of elif are evaluated top to bottom and the first true branch wins. When every branch compares the same variable against fixed values or patterns, case is usually cleaner.

$ for used in 45 82 97; do
>   if (( used >= 95 )); then
>     level=critical
>   elif (( used >= 80 )); then
>     level=warning
>   else
>     level=ok
>   fi
>   echo "$used% -> $level"
> done

45% -> ok
82% -> warning
97% -> critical

&& and || as short conditionals

a && b runs b only if a succeeded; a || b runs b only if a failed. For a single action they read well, especially as guard clauses at the top of a script that exit early when a precondition does not hold.

#!/usr/bin/env bash
die() { echo "report.sh: $*" >&2; exit 1; }
[[ $# -eq 1 ]] || die "usage: report.sh FILE"
[[ -r $1 ]]    || die "cannot read $1"
echo "$1 has $(wc -l < "$1") lines"

$ bash report.sh todo.txt
> bash report.sh nope.txt

todo.txt has 5 lines
report.sh: cannot read nope.txt

a && b || c is not if-then-else

It is tempting to write test && then-part || else-part. But || reacts to the status of everything before it, including b. If the "then" command itself fails, the "else" command runs too.

$ [[ -f todo.txt ]] && grep -q "release" todo.txt || echo "todo.txt does not exist"
> if [[ -f todo.txt ]]; then grep -q "release" todo.txt; else echo "todo.txt does not exist"; fi
> echo "if status: $?"

todo.txt does not exist
if status: 1

Conditions and set -e

With set -e, a failing command normally ends the script. Commands used as conditions are exempt, because failing is their way of saying "false": the command after if, elif, while and until, anything negated by !, and every command in an && or || list except the last.

#!/usr/bin/env bash
set -e
if grep -q "release" todo.txt; then echo "found"; else echo "not found"; fi
grep -q "release" todo.txt && echo "found"
echo "still running"
grep -q "release" todo.txt
echo "never printed"

$ bash check.sh

not found
still running

Testing output, not status

Sometimes the question is "did this print anything?" rather than "did it succeed?". [[ -n $(cmd) ]] tests for non-empty output. When the output could be large, a command with a meaningful status, like grep -q or find ... -print -quit, is cheaper.

$ if [[ -n $(find logs -name '*.log' -size +500c) ]]; then
>   echo "some logs are over 500 bytes:"
>   find logs -name '*.log' -size +500c
> fi
> if [[ -z $(find logs -name '*.gz') ]]; then echo "no compressed logs yet"; fi

some logs are over 500 bytes:
logs/app.log
no compressed logs yet