Conditionals: Making Decisions

Every script you've written so far runs top to bottom, every line, every time. That's a recipe with no judgement — it can't say "only restart the service if it's actually down" or "stop if the backup directory is missing." Conditionals add the judgement. Before the syntax, you need the one idea that makes all of Bash's decision-making click, because it's genuinely different from most languages:

Bash has no true and false. It has exit codes. Every command you run — ls, grep, mkdir, all of them — finishes with a hidden number called its exit code. Zero means "I succeeded." Anything else means "I failed" (and which non-zero number often says how). You've been generating exit codes all along without looking at them.

So what does if actually test? `if` runs a command and reads its exit code. Exit 0 → the then branch runs. Anything else → it doesn't. That's the whole mechanism. Even the square-bracket comparisons you're about to meet aren't special syntax — [ is a command (really — try which [) whose job is to evaluate a comparison and exit 0 or 1.

Think of it like a relay race: each command finishes and hands a baton to whatever's next. A green baton (0) says go; a red baton (non-zero) says don't. if is just a runner who looks at the baton before choosing a lane.

Now the syntax. An if needs four keywords — if, then, the body, and fi (yes, if spelled backwards — that's how Bash closes it). elif and else are optional middle floors. Read this shape out loud until it's boring: if this command succeeds, then do these lines, otherwise do those, done.

Most of the time, though, you're not testing whether a program succeeded — you're comparing values: is this variable empty? is that number bigger than 5? For that, Bash gives you the test command and its famous alias: [. These two lines are identical:

```bash

test -n "$name"

[ -n "$name" ]

`

Because [ is a command, the shell's normal rules apply — and that explains the syntax errors that bite every newcomer: the spaces inside `[ ]` are mandatory (they separate the command from its arguments), and the closing ] is literally the last argument.

Here's where Bash differs from every calculator you've used: it has separate comparison operators for numbers and for text, and it will not stop you from using the wrong ones. Numbers use letter operators (-eq, -gt, …); strings use symbols (=, !=). It feels backwards — stay with it, there's a logic: < and > already mean redirection in the shell, so early Unix picked letters for arithmetic to avoid the clash.

The letter operators read as abbreviations: equal, not equal, greater than, greater-or-equal, less than, less-or-equal.

The most common decision a sysadmin script makes isn't about numbers or strings — it's about the filesystem. Does the config exist? Is it readable? Is that path a directory or a file? Acting without checking is how scripts overwrite data, crash mid-run, or mkdir into an error. File tests are single-flag questions you ask [ — each one takes a path and answers with an exit code.

The ones you'll use constantly: -e exists (any type), -f regular file, -d directory, -r/-w/-x readable/writable/executable by you, and -s non-empty (size > 0).

Real decisions are compound: if the file exists AND we're root… if the host is down OR the disk is full… You already know the operators from the command line — && (and) and || (or) — and they chain tests exactly the way they chain commands, short-circuiting as they go: && stops at the first failure, || stops at the first success.

Bash also has a second, newer test syntax: double brackets `[[ ]]`. It's not a command like [ — it's shell syntax, and because Bash parses it before expanding variables, the empty-variable crash you met earlier simply can't happen. It also adds two abilities [ doesn't have: glob matching with == and regex matching with =~.

Some decisions aren't yes-or-no. Is this file a log, an archive, or something else? Did the operator pick 1, 2 or q? You could write that as if [ "$x" = a ]; elif [ "$x" = b ]; elif …, but Bash has a statement built for it: `case`. It takes one value and compares it against a list of patterns, top to bottom, and runs the commands of the first pattern that matches.

`

case "$value" in

pattern1) commands ;;

p2|p3) commands ;;

*) fallback ;;

esac

`

The pieces: each pattern ends with ), each branch ends with ;;, and the block closes with esac (case spelled backwards, like fi). The patterns are globs, the same wildcards as filenames: * is any text, ? is one character, [A-Z] is a character class, and | means or. A final *) matches anything that fell through. That makes it your else branch, so input you didn't expect gets a message instead of silence.

Put a case inside a while loop and you have an interactive menu: print the options, read a choice, dispatch on it with case, repeat. Two details make a menu robust. `read … || break` leaves the loop when input ends: read fails at end-of-file, so a script fed from a pipe stops cleanly instead of looping forever. And a quit branch that runs `break` gives the operator a way out. (Bash also has a select builtin that prints a numbered menu for you. It uses the same case-inside-a-loop shape.)

Time to make decisions for real. In your terminal, you'll build the single most useful conditional pattern in operations — check, then act, and say what you did — and deliberately trigger both branches so you see the decision happen. Type these; don't paste. The syntax needs to reach your fingers.