Conditionals and test

A conditional in the shell does not test "true" or "false" the way most languages do — it runs a command and branches on that command's exit status. Exit code 0 means success and is treated as true; any non-zero code is false. if cmd; then ...; fi simply runs cmd and looks at $?. The thing people call "the test" — [ ... ], its synonym test, and Bash's [[ ... ]] — is just a command whose whole job is to evaluate an expression and exit 0 or 1.

That detail decides how scripts behave under failure. Because [ is an ordinary command, every operand is a word the shell expands first, so an unquoted empty variable silently vanishes and turns a valid-looking test into a syntax error or a wrong answer. On Debian and Ubuntu the default /bin/sh is dash, not Bash, so [[ ]] and == are unavailable in #!/bin/sh scripts — getting the shebang wrong is a common cause of "works on my laptop, breaks in cron".

Exit Status as the Boolean

There is no boolean type in the shell. The condition after if, while, or && is a command, and its exit status is the decision. This is why you write if grep -q root /etc/passwd; then directly rather than capturing output and comparing it — grep already returns 0 when it matches and 1 when it does not. Wrapping such a command in [ "$(...)" ] is redundant and slower.

# Branch on a command's exit status, not its output
if systemctl is-active --quiet nginx; then
    echo "nginx is running"
elif systemctl is-failed --quiet nginx; then
    echo "nginx failed"
else
    echo "nginx is stopped"
fi

The same logic powers the short-circuit operators. cmd1 && cmd2 runs cmd2 only if cmd1 succeeded; cmd1 || cmd2 runs cmd2 only if cmd1 failed. They read cleanly for one-liners — mkdir -p /opt/app && cd /opt/app — but they are not a substitute for if when the "then" branch itself can fail, because the exit status of the whole chain becomes that of the last command run.

test, [ and [[

test EXPR and [ EXPR ] are the same POSIX builtin; the [ form just requires a closing ] as its final argument, which is why the space before ] is mandatory. They support file tests (-f, -d, -e, -r, -x), string tests (-z for empty, -n for non-empty, = and !=), and numeric tests with worded operators (-eq, -ne, -lt, -gt, -le, -ge). The numeric operators are words on purpose: < and > inside [ ] are redirections, not comparisons.

[[ EXPR ]] is a Bash keyword, not a command, so the shell parses it as a unit and does not word-split or glob-expand its operands. That removes the entire class of "unquoted empty variable" bugs, adds =~ for regex matching and </> for lexical string comparison, and lets == do glob pattern matching on the right-hand side. The cost is portability: [[ ]] exists in Bash, ksh, and zsh but not in dash, so a #!/bin/sh script that uses it fails the moment Debian or Ubuntu runs it under dash.

Capability	[ ] / test	[[ ]]
Defined by	POSIX builtin (command)	Bash keyword
Word-splits / globs operands	Yes — must quote	No — quoting optional
String equality	=	= or == (glob on RHS)
Regex match	No	=~
Combine conditions	-a / -o (deprecated)	&& / ||
Works under dash / /bin/sh	Yes	No

Quoting and Empty Operands

Inside [ ] the shell expands variables before test ever sees them, so an empty or unset variable disappears entirely. [ $x = yes ] with x empty becomes [ = yes ], which is a syntax error; with x="a b" it becomes [ a b = yes ], too many arguments. Quoting every operand — [ "$x" = yes ] — collapses the expansion to a single argument and the test behaves. This is the single most common defect in shell scripts that pass casual testing and break on the first odd input.

# Unquoted: breaks when $1 is empty or contains spaces
if [ -z $1 ]; then echo "missing arg"; fi    # wrong

# Quoted: correct under [ ]
if [ -z "$1" ]; then echo "missing arg"; fi

# [[ ]] does not word-split, so this is safe even unquoted (Bash only)
if [[ -z $1 ]]; then echo "missing arg"; fi

With set -u in effect — which any careful script enables — an unset variable is a hard error before the test even runs, so [ -z "$1" ] aborts when $1 was never passed. Guard it with a default: [ -z "${1:-}" ]. The old defensive trick of writing [ "x$x" = "xyes" ] predates reliable quoting and is no longer needed; quote the variable instead.

Arithmetic and Pattern Matching

For numeric work, (( EXPR )) evaluates a C-style arithmetic expression and sets exit status from the result — non-zero value is true, zero is false. if (( count > 5 )) reads naturally and uses real >, <, ==, and % operators instead of -gt and friends. It is Bash-only, like [[ ]]; under dash use [ "$count" -gt 5 ]. A subtle trap: (( count )) where count is 0 returns exit status 1, so set -e scripts can exit unexpectedly on a legitimate zero.

For string matching, [[ $file == *.log ]] does glob matching on the unquoted right-hand side, and [[ $ip =~ ^[0-9]+\.[0-9]+ ]] matches a POSIX extended regex, exposing capture groups in BASH_REMATCH. The regex pattern must be unquoted or stored in a variable; quoting it turns the match into a literal string comparison. When a value can take several discrete forms, case is clearer than a stack of elif branches, because each glob pattern is matched in order and the first match wins.

# case branches on glob patterns, first match wins
case "$1" in
    start|restart)  systemctl restart myapp ;;
    stop)           systemctl stop myapp ;;
    *.conf)         echo "got a config file: $1" ;;
    *)              echo "usage: $0 {start|stop|restart}"; exit 2 ;;
esac