In the three previous lessons you have written if, case and [[ ]] guided by their resemblance to other languages. It worked, but you did not know why. Time to fix that, starting with the idea that governs everything in Bash and that hardly any tutorial states clearly: here you do not branch on a boolean value, you branch on a command's exit code. if does not expect an expression: it expects a command, runs it and checks whether it returned 0; everything else — [ ], [[ ]], (( )) — are commands that exist in order to produce that 0 or 1. With that piece in place, the rest falls into position on its own. By the end, health_check.sh will be able to say OK, WARN or CRITICAL, and purge_releases.sh will be born.

1. The condition is an exit code
2. if, elif, else
3. The three kinds of test and which to use
4. Complete table of operators
5. Regular expressions with =~ and BASH_REMATCH
6. case and its three terminators
7. Loops: for, while, until
8. break, continue and select
9. Short circuits && and ||, and their trap
10. Loops and performance: when you want awk
11. Application: alert levels and purge_releases.sh

There is no == true anywhere. if ran grep -q, grep returned 0 because it found matches, and 0 means success, so the then was entered. Had it found nothing it would have returned 1 and the block would have been skipped.

Three consequences worth keeping in mind from now on:

• Any command can be a condition: if ping -c1 -W2 10.0.2.15, if [[ -f file ]], if my_function. They are all the same thing. And the classic [ is a real command, with its executable in /usr/bin/[; that is why [ $a = $b ] needs spaces: they are separate arguments.
• The logic is inverted compared with languages that have booleans: 0 is true. If you write a function that checks something, it must return 0 when the answer is "yes".

The syntax requires then and fi; the ; before then lets you put it on the same line. The elifs are evaluated in order and the first one that matches wins, so the conditions go from the most restrictive to the loosest: if you swapped the first two blocks, a disk at 95% would say WARN. To negate, put ! in front: if ! systemctl is-active --quiet tramontana; then .... And beware of if [ $? -eq 0 ], almost always redundant: put the command directly in the if.

The difference between [ ] and [[ ]] is not cosmetic. [[ ]] is shell syntax, not a command, so Bash does not do word splitting or glob expansion inside it:

With [ ] the unquoted variable was split into two arguments and the command could not even be evaluated. With [[ ]] there is no need to quote, and it also accepts &&, ||, patterns and =~, which [ ] does not have. For numbers, (( )) is far more readable: compare if (( errors > 20 && connections >= 200 )) with [ "$errors" -gt 20 -a "$connections" -ge 200 ]. Remember from 04-02 that inside (( )) the variables go without $.

The classic confusion deserves a warning in bold: -eq is for numbers and == is for strings. [[ "01" -eq "1" ]] is true (numerically equal) but [[ "01" == "1" ]] is false (different strings). Using the wrong operator gives correct results for months and then fails with a leading zero or with a version like 3.10.

Another surprising detail: inside [[ ]], the right-hand side of == is not quoted if you want it to be a pattern:

The quotes turn the pattern into literal text: it is the number one source of "my comparison does not work and I do not know why".

=~ compares against an extended regular expression (the ERE from 03-02) and, as well as saying yes or no, leaves the captures in the BASH_REMATCH array: position 0 is the whole match and the following ones are the parenthesised groups.

With this you validate the date column of bookings.csv before trusting it. Two golden rules: the regex does not go in quotes — quote it and it becomes literal text, just as with == — and if you store it in a variable, use that unquoted too: [[ $f =~ $PATTERN ]].

case compares a string against globbing patterns — not regular expressions — and runs the first branch that matches.

The order matters: 404 comes before 4* because the first match wins. | separates alternatives and *) is the default case, which goes last and is always worth including. The three terminators:

;;& is rare but useful for cumulative labels; ;& is dangerous because a distracted reader does not see it. Use them only with a comment justifying it.

The second form — iterating over a glob — is the correct one for walking through files, and it brings two warnings. The first: if the glob finds nothing, Bash leaves the literal pattern and the loop runs once with /var/log/tramontana/*.log as the value; hence the [[ -e ... ]] || continue, or else shopt -s nullglob from 03-02. The second, more important:

Never write for f in $(ls).

You will see it on the internet constantly and it is wrong for three cumulative reasons: ls returns text that the shell splits on spaces, so "august report.txt" becomes two elements; special characters in the name are expanded as globs; and ls can colour or align its output depending on options and aliases. The glob has none of those problems because Bash works with real file names, not with text. And there is the arithmetic form, for (( i = 0; i < ${#versions[@]}; i++ )), for when the index matters.

while repeats while the condition returns 0; until repeats until it returns 0. They are the same structure with the condition negated, and until wins when the natural phrasing is "wait until":

That loop is the one a deployment needs in order to wait for the service to be ready, and we will reuse it in 04-07. You also already know the while read from 04-03, which is the third common use.

break leaves the loop and continue jumps to the next iteration. Both accept a number saying how many levels they affect: break 2 leaves two nested loops in one go.

If you find yourself with three levels of nesting, that is not a loop problem: it is a function you have not written yet, and we will look at it in 04-05. As for select, it is a loop and without break it never ends; PS3 is the prompt text and $REPLY holds what the user typed.

You have been using them since 02-01: A && B runs B only if A succeeded; A || B runs B only if A failed. As a one-line conditional they are unbeatable: [[ -d $DIR ]] || mkdir -p "$DIR", or command -v shellcheck >/dev/null || { echo "shellcheck is missing" >&2; exit 69; }. But a lot of people write condition && action || something_else believing it is an if/else, and it is not:

The key: || does not look at the condition, it looks at the result of the previous action. If the action fails for any reason — a mkdir without permission, a grep with no matches — the || branch runs as well as the && one. The rule: chain && and || only when the action cannot fail; as soon as there is a genuine else, use if.

This section will save you hours of waiting. Let us count the 14 responses with code 500 in access.log in two ways:

Three hundred times faster, and that is with only 412 lines. The cause is not that Bash interprets slowly: it is that the loop launches a grep process for every line, and creating a process costs a few milliseconds that multiply up. With the 10,000 lines access.log will have in a month, the loop would take almost a minute and awk would still be in hundredths. The rule:

• If the loop processes text line by line, you probably want awk (or grep, sed, sort), which do a single pass inside a single process.
• If the loop has to call an external command on every turn — curl, systemctl, tar — then it really is Bash's work, because there is no alternative. And if you need Bash over text, at least do not launch processes inside: read with several names, case and parameter expansion do a great deal without leaving the shell.

health_check.sh finally decides. We replace the printing block with checks that carry a level:

With those codes — 0 correct, 1 warning, 2 critical — the script is now fit for monitoring: Nagios, Zabbix and company use exactly that convention. And now the new script:

Exactly what we wanted: only 3.1.0 is purgeable. Note two defensive details: rm -rf -- "${RELEASES_DIR:?}/$v" uses ${VAR:?} from 04-02 so that, if the variable were left empty by a bug, the command aborts instead of turning into rm -rf /; and -- stops a directory name with a leading hyphen being read as an option.

• Forgetting the spaces inside [ ] or [[ ]]. [[$a == $b]] gives command not found: the brackets are commands and reserved words, not syntax glued to the operands.
• Mixing -eq with strings or == with numbers. [[ "3.10" > "3.9" ]] is false lexicographically: for versions, sort -V; for numbers, (( )). And do not quote the right-hand side of == or =~, or the pattern becomes literal text.
• for f in $(ls). It breaks with spaces and with special characters; always use the glob. And protect the glob with no matches using [[ -e $f ]] || continue or shopt -s nullglob, or the loop will run once with the literal pattern.
• Trusting cond && action || other as an if/else. If action fails, both branches run. And nesting three loops is the unmistakable sign that a function is missing.
• Tip: always compare numbers with (( )): it is more readable and you will not confuse the operator. Always include the *) branch in a case, even if only to log "unexpected value". And before writing a loop that processes text, ask yourself whether awk would do it in a single pass: the answer is nearly always yes.

Exercise 1. Write is_valid_version(), which returns 0 if its argument has the format N.N.N (one or more digits per part) and 1 if not, using =~, and prints the three numbers separately. Test it with 3.2.1, 3.10.0, 3.2 and v3.2.1.

Exercise 2. Write ~/scripts/time_bands_summary.sh, which over access.log classifies each request as night (00-05), morning (06-13), afternoon (14-21) or evening (22-23) with case, and shows requests and errors per band. Do it without launching processes inside the loop and compare the time with awk.

Exercise 3. Luis has written this fragment to decide whether to purge. Find the four flaws and rewrite it.

Solution 1.

The dots are escaped (\.) because in a regex . means "any character"; unescaped, 3x2y1 would be valid too. And notice how the function is used directly in the if: that is section 1 in action. (With no explicit return 0, the function returns the code of the printf, which is 0.)

Solution 2.

The 15 errors during the night are the ones from the 03:00 band you already know about, and the 23 in total add up. The awk version — one line with substr($2,1,2)+0 and a ternary for the band — takes 0.007 s: seven times less, even with no processes inside the loop, purely because of the interpreter's overhead. But look at the scale: hundredths against hundredths. The catastrophic difference appears when there is a $(...) inside the loop, not because of the loop itself. And note the [45]* pattern in the case: globbing, not regex.

Solution 3. The four flaws:

1. ` ` instead of $( ). Backticks do not nest, they have different escaping rules and they are unreadable. Besides, df's $5 includes the %, so the numeric comparison receives 30%.
2. [ $free > 80 ]. Inside [ ], > does not compare: it is a redirection, so that command creates a file called 80 in the current directory and the test is always true. You have to use -gt or, better, (( )).
3. rm -rf /opt/tramontana/releases/* deletes everything, including the active release the app link points to: the application goes down instantly.
4. echo ... && rm ... || echo "error". If the rm partially fails, both messages are printed and the script returns no useful code. On top of that there is no --dry-run and no record of what was deleted.

The destructive logic is delegated to purge_releases.sh, which already knows what to keep, has a --dry-run and logs what it does. Reusing instead of rewriting is also a control structure.

You no longer write conditionals by imitation: you know what happens underneath.

• You are clear that the condition is an exit code, that 0 is success, and that any command — including a function of your own — can go in an if.
• You use if/elif/else ordering from the most restrictive condition to the loosest, and you choose between the three kinds of test: [[ ]] by default because it does not split words and it accepts patterns, (( )) for anything numeric, and [ ] only if you need POSIX.
• You handle the complete table of operators for files, strings and numbers; you do not confuse -eq with == and you do not quote the right-hand side of a pattern; you validate with =~ and BASH_REMATCH, with the regex unquoted and anchored with ^ and $; and you write case with globbing patterns, the mandatory *) and the ;;, ;& and ;;& terminators.
• You iterate with for over globs, never over $(ls), with the arithmetic form when the index matters, and with while/until for waits and reads; you control the flow with break N, continue N and select. You know the trap of cond && action || other and the performance rule: if the loop processes text, you probably want awk, measured on a real case.
• And your scripts decide: health_check.sh returns OK, WARN or CRITICAL with codes fit for monitoring, and purge_releases.sh walks the releases keeping the active one, the previous one and the newer ones.

Now look at the scripts side by side: log() is copied three times, error() as well, the run() wrapper is on its second copy and the getopts block is nearly identical in all of them. Every time you improve one you will have to remember to improve the others, and one day you will not remember. In the next lesson, Functions and Libraries, we solve that: when to extract a function and why the name is documentation, Bash's dynamic scope and why every variable must be local, the three real ways of returning data when return only accepts a number from 0 to 255, and how to build lib/common.sh with robust loading, include guards and even a small test that checks the library works. By the end of it, those duplicated functions will live in a single place.