Overview

This page is the spaced-repetition companion to the Just Enough Bash primer: five fixed drills that force active recall instead of passive re-reading. Work through them in order -- short-answer recall first, then scenario judgment, then hands-on repetition, then a checklist to confirm real automaticity, and finally why/why-not prompts that test whether you can explain the reasoning, not just execute the syntax. Every answer is hidden in a <details> block; try each item yourself before opening it.

Recall Q&A

Twenty-six short-answer questions, one per concept (co-01 through co-26). Answer from memory, then check.

Q1 (co-01 -- shebang-and-execution). What two things make a .sh file a directly runnable program, and what's the alternative if you skip both?

Q2 (co-02 -- interactive-vs-script). What's the key behavioral difference between Bash running interactively at a prompt and Bash running a script non-interactively?

Q3 (co-03 -- strict-mode). What does each of the three flags in set -euo pipefail do on its own?

Q4 (co-04 -- bash-vs-posix). Name three syntax features Bash adds on top of portable POSIX sh.

Q5 (co-05 -- variables-and-expansion). What does ${v:-default} do differently from plain $v when v is unset?

Q6 (co-06 -- quoting). What's the practical difference between single quotes, double quotes, and no quotes around $var in Bash?

Q7 (co-07 -- command-substitution). What does $(...) capture, and what's the older, now-discouraged syntax for the same thing?

Q8 (co-08 -- arithmetic-expansion). What does $(( )) let you avoid calling?

Q9 (co-09 -- exit-codes). What does exit code 0 mean, and how does a script set its own final exit code?

Q10 (co-10 -- conditionals). Name the three families of if test Bash supports and what each tests.

Q11 (co-11 -- case-statement). When is case ... esac a better choice than a chain of if/elif?

Q12 (co-12 -- loops). Name Bash's three loop forms and what break/continue do inside any of them.

Q13 (co-13 -- functions). What does local do inside a Bash function, and what happens if you forget it?

Q14 (co-14 -- io-redirection). What's the difference between > and >>, and what does 2>&1 do?

Q15 (co-15 -- pipes). What exactly does | connect between two commands?

Q16 (co-16 -- here-docs-and-strings). What's the difference between <<EOF and <<'EOF', and what does <<< do?

Q17 (co-17 -- read-input). What does the -r flag to read protect against?

Q18 (co-18 -- text-pipeline-tools). Name at least five of the single-purpose text tools this primer chains together in pipelines, and what each one does in one phrase.

Q19 (co-19 -- positional-parameters). What's the difference between "$@" and "$*" when a script has an argument containing a space, and what does shift do?

Q20 (co-20 -- getopts). What does the leading : in an option string like ":i:o:h" change about getopts's own error reporting?

Q21 (co-21 -- trap-and-cleanup). What are the three signal/event names this primer's trap examples register handlers for, and what does each cover?

Q22 (co-22 -- mktemp). Why use mktemp instead of hand-writing a temp filename like /tmp/scratch.txt?

Q23 (co-23 -- globbing). What does an unquoted *.txt glob expand to when NO file matches it, and why does that matter in a loop?

Q24 (co-24 -- regular-expressions). What's the difference between grep 'ERROR' and grep -E '^ERROR'?

Q25 (co-25 -- shellcheck-and-shfmt). What does shellcheck check for that shfmt does not, and vice versa?

Q26 (co-26 -- process-substitution). What does <(cmd) let you pass to a command that normally expects a filename argument?

Applied problems

Thirteen scenarios. Each describes a task without naming the construct -- decide which Bash feature or tool solves it, then check.

AP1. A deploy script must abort immediately the moment ANY step fails, rather than plowing ahead and leaving the system half-configured, and it should also catch typos in variable names instead of silently treating them as empty strings.

AP2. A backup script builds a destination path from a variable that might contain a space (a real folder named "Q1 Reports"), and a teammate's cp $src $dest keeps failing with confusing "too many arguments" errors whenever that folder is involved.

AP3. A script needs to know today's four-digit year to name a log file, without hardcoding a value that will be wrong next year.

AP4. A CI script runs a linter across 200 files and needs to know, at the very end, whether ANY single file failed -- even though the loop itself always reaches its final line and the script's own last command (printing a summary) always succeeds.

AP5. A script accepts an optional -o <output> flag; when the user doesn't pass -o at all, it should quietly fall back to ./out.txt rather than requiring the flag every time.

AP6. A monitoring script polls a health-check URL every few seconds; a teammate wants to add Ctrl-C handling so that interrupting the script prints a friendly "stopped by user" message instead of the terminal's raw "^C" and an abrupt kill.

AP7. A script generates a large report by writing directly to its -o output path as it goes; a teammate wants to guarantee that if the script crashes halfway through, readers never see a truncated, half-written report sitting at that path.

AP8. A script needs to process every *.log file in a directory, but that directory is sometimes genuinely empty of .log files, and the script must handle that case cleanly rather than trying to process a nonexistent file named literally *.log.

AP9. A validation script wants to count how many lines in a log genuinely START with the word ERROR (a real error entry), without also matching an unrelated debug line like last_ERROR_count=0 that merely contains the same word mid-line.

AP10. A script needs to compare the sorted contents of two files to see if they contain the same set of lines, without leaving any temp files behind afterward and without a separate sort a > /tmp/a.sorted; sort b > /tmp/b.sorted; diff ...; rm /tmp/a.sorted /tmp/b.sorted dance.

AP11. A code-review checklist item flags a script for review because it hardcodes /tmp/myapp-scratch.txt as its working file, and two people running the deploy script at the same time on the same shared build server would stomp on each other's scratch data.

AP12. A script parses -i <input> and -o <output> with getopts, and correctly prints a usage message when it sees an option it doesn't recognize -- but running it with ZERO options at all (neither -i nor -o) still limps forward and fails later with a confusing, unrelated file-not- found error instead of a clear "missing required option" message.

AP13. A script that runs fine on the author's Ubuntu laptop needs to also run, unmodified, in a minimal Alpine container whose /bin/sh is dash, not Bash -- and the author needs to know which of their script's constructs will simply not work there.

Code katas

Eight hands-on repetition drills. Each is a before/after .sh file pair colocated under drilling/code/. Every "before" script is a real, runnable Bash program that misapplies the concept being drilled -- run it yourself, diagnose the bug from the observed behavior, fix it from memory, then compare your fix against the "after" script and the real output shown.

Kata 1 -- unquoted word splitting

Task. A script checks whether a file named "my notes.txt" exists using [ -f $file ] (no quotes around $file). Run it and diagnose why it reports "not found" for a file that was just created moments earlier in the very same script.

Before (drilling/code/kata-01-unquoted-word-splitting/before/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
file="my notes.txt"
touch "$file"
if [ -f $file ]; then
  echo "found: $file"
else
  echo "not found (word-split bug)"
fi
rm -f "$file"

Observed (buggy) output (captured by actually running the script above):

kata.sh: line 5: [: my: binary operator expected
not found (word-split bug)

After (drilling/code/kata-01-unquoted-word-splitting/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
file="my notes.txt"
touch "$file"
if [ -f "$file" ]; then
  echo "found: $file"
else
  echo "not found (word-split bug)"
fi
rm -f "$file"

Fixed output:

found: my notes.txt

Why it happens: unquoted $file word-splits on the space, so [ -f $file ] actually runs as [ -f my notes.txt ] -- three arguments where test -f expects exactly one, which is a genuine test syntax error ("binary operator expected"), not a clean pass/fail. shellcheck catches this exact pattern as SC2086 ("Double quote to prevent globbing and word splitting").

Kata 2 -- missing pipefail

Task. A script reads a (missing) file through a pipeline, cat missing.txt | wc -l, under set -eu but WITHOUT pipefail. Diagnose why the script keeps running past the cat failure instead of stopping.

Before (drilling/code/kata-02-missing-pipefail/before/kata.sh)

#!/usr/bin/env bash
set -eu
# Kata 2 (BUGGY): cat on a missing file fails, but without 'pipefail' the
# pipeline's exit status comes from the LAST command (wc -l), which still
# succeeds on empty input -- masking the real cat failure completely.
cat /tmp/kata2-does-not-exist.txt | wc -l
echo "pipeline reported success (exit 0) even though cat genuinely failed above"

Observed (buggy) output (captured by actually running the script above):

cat: /tmp/kata2-does-not-exist.txt: No such file or directory
       0
pipeline reported success (exit 0) even though cat genuinely failed above

After (drilling/code/kata-02-missing-pipefail/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 2 (FIXED): 'pipefail' makes the pipeline's exit status the FIRST
# non-zero status among all stages, so cat's real failure propagates and
# 'set -e' now correctly aborts the script instead of silently continuing.
cat /tmp/kata2-does-not-exist.txt | wc -l
echo "this line never runs -- the script already aborted above"

Fixed run (script now aborts before the final echo):

cat: /tmp/kata2-does-not-exist.txt: No such file or directory
       0
$ echo $?
1

Why it happens: in a pipeline, $? (and what set -e checks) reflects only the LAST command's exit status by default -- wc -l always succeeds, even reading zero lines from cat's empty output, so cat's real failure never reaches set -e at all without pipefail.

Kata 3 -- off-by-one loop range

Task. A retry loop is meant to attempt a task 3 times (attempts 1, 2, 3) but its while condition uses -lt instead of -le. Run it and count how many attempts actually happen.

Before (drilling/code/kata-03-off-by-one-range/before/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 3 (BUGGY): meant to attempt a task up to 3 times (attempts 1, 2, 3),
# but the loop guard uses -lt instead of -le, so it only runs twice.
max_attempts=3
attempt=1
while [ "$attempt" -lt "$max_attempts" ]; do
  echo "attempt $attempt of $max_attempts"
  attempt=$((attempt + 1))
done
echo "loop ran $((attempt - 1)) time(s), expected $max_attempts"

Observed (buggy) output:

attempt 1 of 3
attempt 2 of 3
loop ran 2 time(s), expected 3

After (drilling/code/kata-03-off-by-one-range/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 3 (FIXED): -le (less-than-or-equal) makes the loop run exactly
# max_attempts times, attempts 1 through 3 inclusive.
max_attempts=3
attempt=1
while [ "$attempt" -le "$max_attempts" ]; do
  echo "attempt $attempt of $max_attempts"
  attempt=$((attempt + 1))
done
echo "loop ran $((attempt - 1)) time(s), expected $max_attempts"

Fixed output:

attempt 1 of 3
attempt 2 of 3
attempt 3 of 3
loop ran 3 time(s), expected 3

Why it happens: -lt (less-than) stops the loop the moment attempt reaches max_attempts, one iteration short of running with attempt == max_attempts itself; -le (less-than-or-equal) includes that final boundary value. shellcheck cannot catch this one -- it's a logic error, not a syntax pattern, so it takes reading the loop guard carefully.

Kata 4 -- getopts without a required-option check

Task. A script parses -i <input> with getopts and correctly rejects unknown flags, but never checks that -i was actually supplied. Run it with no options at all and diagnose the resulting error.

Before (drilling/code/kata-04-getopts-missing-required/before/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 4 (BUGGY): parses -i but never checks it was actually supplied,
# so running the script with no options at all silently proceeds with an
# empty $input and fails later with a confusing, unrelated error.
input=""
while getopts ":i:" opt; do
  case "$opt" in
  i) input="$OPTARG" ;;
  *)
    echo "usage: kata.sh -i <input>" >&2
    exit 1
    ;;
  esac
done
 
echo "reading from: '$input'"
wc -l <"$input"

Observed (buggy) output (running kata.sh with zero arguments):

reading from: ''
kata.sh: line 18: : No such file or directory

After (drilling/code/kata-04-getopts-missing-required/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 4 (FIXED): explicitly validates that -i was supplied, with a clear
# usage message, before ever touching $input.
input=""
while getopts ":i:" opt; do
  case "$opt" in
  i) input="$OPTARG" ;;
  *)
    echo "usage: kata.sh -i <input>" >&2
    exit 1
    ;;
  esac
done
 
if [ -z "$input" ]; then
  echo "kata.sh: -i <input> is required" >&2
  exit 1
fi
 
echo "reading from: '$input'"
wc -l <"$input"

Fixed output (running with zero arguments):

kata.sh: -i <input> is required

Why it happens: getopts only validates the options it actually sees in $@ -- it has no built-in concept of "this flag is mandatory." Skipping the flag entirely just means the loop body never runs for i, leaving input at its empty default, and the real failure only surfaces two lines later as a confusing, unrelated No such file or directory.

Kata 5 -- missing trap cleanup

Task. A script creates a mktemp scratch file, then hits a simulated failure (false) before finishing. Run it, check whether the scratch file survives the failure, then fix it.

Before (drilling/code/kata-05-trap-cleanup-missing/before/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 5 (BUGGY): creates a scratch file but never registers a trap to
# clean it up, so a mid-script failure leaves it behind forever.
scratch="$(mktemp /tmp/kata5-scratch.XXXXXX)"
echo "working in $scratch"
echo "partial output" >"$scratch"
 
# Simulate a real failure partway through the script.
false
echo "this line never runs"

Observed (buggy) run (the scratch file is LEAKED -- still present after the script exits non-zero):

$ bash kata.sh; echo "exit: $?"
working in /tmp/kata5-scratch.Xjfahe
exit: 1
$ ls /tmp/kata5-scratch.*
/tmp/kata5-scratch.Xjfahe

After (drilling/code/kata-05-trap-cleanup-missing/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 5 (FIXED): trap 'rm -f "$scratch"' EXIT runs on ANY exit path --
# normal completion, explicit exit, or an uncaught failure -- so the
# scratch file is guaranteed to be cleaned up.
scratch="$(mktemp /tmp/kata5-scratch.XXXXXX)"
trap 'rm -f "$scratch"' EXIT
echo "working in $scratch"
echo "partial output" >"$scratch"
 
# Simulate the same real failure partway through the script.
false
echo "this line never runs"

Fixed run (the scratch file is cleaned up even though the script still fails):

$ bash kata.sh; echo "exit: $?"
working in /tmp/kata5-scratch.kI5Los
exit: 1
$ ls /tmp/kata5-scratch.*
zsh: no matches found: /tmp/kata5-scratch.*

Why it happens: without a registered trap, nothing ever runs rm on the scratch file when the script exits early via set -e -- trap '...' EXIT is the only mechanism that guarantees cleanup code runs on EVERY exit path, success or failure, so it must be registered immediately after the file is created, before any code that could fail.

Kata 6 -- glob with no no-match guard

Task. A script loops for f in *.txt in a directory that has zero .txt files. Run it and diagnose the confusing error about a file that was never actually created.

Before (drilling/code/kata-06-glob-no-match-guard/before/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
scratch_dir="$(mktemp -d)"
cd "$scratch_dir"
# Kata 6 (BUGGY): no .txt files exist in this empty scratch dir, but
# without a no-match guard the loop still "processes" the literal,
# unexpanded glob pattern itself as if it were a real filename.
for f in *.txt; do
  echo "processing: $f"
  wc -l "$f"
done
cd /
rm -rf "$scratch_dir"

Observed (buggy) output:

processing: *.txt
wc: *.txt: open: No such file or directory

After (drilling/code/kata-06-glob-no-match-guard/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
scratch_dir="$(mktemp -d)"
cd "$scratch_dir"
# Kata 6 (FIXED): [[ -e "$f" ]] || continue skips the loop body when the
# glob matched nothing and bash left it as the literal, unexpanded pattern.
for f in *.txt; do
  [[ -e "$f" ]] || continue
  echo "processing: $f"
  wc -l "$f"
done
echo "no .txt files found -- loop body never ran, no error"
cd /
rm -rf "$scratch_dir"

Fixed output:

no .txt files found -- loop body never ran, no error

Why it happens: Bash's default globbing behavior leaves an unmatched pattern completely unexpanded rather than producing zero words, so the loop still runs exactly once with f bound to the literal four-character string *.txt -- a real file path is then handed to wc -l, which correctly reports it doesn't exist.

Kata 7 -- unanchored regex mid-line false match

Task. A log-scanning script counts lines matching ERROR to report an error count, but its pattern has no anchor. Given a log with one harmless debug line containing "ERROR" mid-word, run it and check whether the count is inflated.

Before (drilling/code/kata-07-regex-anchor-mistake/before/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 7 (BUGGY): meant to count lines that START WITH "ERROR", but the
# pattern has no anchor, so it also matches ERROR appearing MID-LINE
# (like the harmless "last_ERROR_count=0" debug line below). The log is
# written here so the kata is self-contained and runnable with no
# pre-existing fixture.
log="kata7-log.txt"
cat >"$log" <<'EOF'
INFO service started
ERROR disk full
DEBUG last_ERROR_count=0
INFO all clear
ERROR connection refused
EOF
matches="$(grep -c 'ERROR' "$log")"
echo "lines counted as errors: $matches"
rm -f "$log"

Observed (buggy) output (running bash kata.sh directly, no setup needed):

lines counted as errors: 3

After (drilling/code/kata-07-regex-anchor-mistake/after/kata.sh)

#!/usr/bin/env bash
set -euo pipefail
# Kata 7 (FIXED): the ^ anchor (via grep -E, though -E is not even
# required for a plain ^ anchor -- kept for consistency with this
# primer's other -E examples) restricts matches to lines that actually
# START WITH "ERROR", excluding ERROR appearing mid-line. The log is
# written here so the kata is self-contained and runnable with no
# pre-existing fixture.
log="kata7-log.txt"
cat >"$log" <<'EOF'
INFO service started
ERROR disk full
DEBUG last_ERROR_count=0
INFO all clear
ERROR connection refused
EOF
matches="$(grep -Ec '^ERROR' "$log")"
echo "lines counted as errors: $matches"
rm -f "$log"

Fixed output (running bash kata.sh directly, same log content):

lines counted as errors: 2

Why it happens: grep 'ERROR' (no anchor) matches "ERROR" appearing anywhere in a line, including the harmless DEBUG last_ERROR_count=0 line, which is not a real error entry at all. ^ERROR restricts the match to lines that genuinely start with "ERROR" -- the two real error log lines, correctly excluding the debug line.

Kata 8 -- unquoted array expansion

Task. A script loops for f in ${files[@]} (unquoted) over an array holding a filename with an embedded space. Run it and count how many loop iterations happen versus how many elements the array actually holds.

Before (drilling/code/kata-08-array-unquoted-expansion/before/kata.sh)

#!/usr/bin/env bash
set -uo pipefail
# Kata 8 (BUGGY): unquoted ${files[@]} word-splits each element on
# whitespace, so "report one.txt" becomes TWO loop iterations instead
# of one.
files=("report one.txt" "report-two.txt")
count=0
# Intentionally unquoted: this IS the kata's bug under test.
# shellcheck disable=SC2068
for f in ${files[@]}; do
  count=$((count + 1))
  echo "element $count: '$f'"
done
echo "total elements seen: $count (array actually holds ${#files[@]})"

Observed (buggy) output:

element 1: 'report'
element 2: 'one.txt'
element 3: 'report-two.txt'
total elements seen: 3 (array actually holds 2)

After (drilling/code/kata-08-array-unquoted-expansion/after/kata.sh)

#!/usr/bin/env bash
set -uo pipefail
# Kata 8 (FIXED): "${files[@]}" quoted preserves each array element as
# ONE word regardless of embedded spaces, matching the array's real length.
files=("report one.txt" "report-two.txt")
count=0
for f in "${files[@]}"; do
  count=$((count + 1))
  echo "element $count: '$f'"
done
echo "total elements seen: $count (array actually holds ${#files[@]})"

Fixed output:

element 1: 'report one.txt'
element 2: 'report-two.txt'
total elements seen: 2 (array actually holds 2)

Why it happens: unquoted ${files[@]} expands each array element and then word-splits the whole result on whitespace, exactly like unquoted $var does -- "report one.txt" becomes two separate loop iterations instead of one. "${files[@]}" (quoted) is the one array-expansion form that preserves each element as exactly one word regardless of embedded spaces; shellcheck flags the unquoted form as SC2068.

Self-check checklist

Confirm each item without checking the manual first. If you hesitate, that concept needs another pass.

• I can name the two things (shebang + executable bit) that make a script directly runnable, and the fallback command if I skip them. (co-01)
• I can explain what a non-interactive script inherits from the calling shell versus what it does not. (co-02)
• I can state what each of -e, -u, and pipefail does on its own, from memory. (co-03)
• I can name at least three Bash-only syntax features that will not run under POSIX sh. (co-04)
• I can write ${v:-default} and ${v:?message} correctly and explain when each fires. (co-05)
• I can predict the outcome of single-quoted, double-quoted, and unquoted $var without running the code. (co-06)
• I can capture a command's output into a variable with $(...) without hesitation. (co-07)
• I can evaluate integer arithmetic with $(( )) instead of reaching for expr. (co-08)
• I can read $? immediately after a command and explain what exit N sets it to. (co-09)
• I can write a string test, a numeric test, and a file test inside [[ ]] without looking up the operators. (co-10)
• I can write a case ... esac that dispatches on glob patterns instead of a chained if/elif. (co-11)
• I can write all three loop forms (for/while/until) and use break/continue correctly inside any of them. (co-12)
• I can define a function that uses local to avoid leaking a variable into the global scope. (co-13)
• I can redirect stdout, append to a file, redirect stderr separately, and merge stderr into stdout with 2>&1. (co-14)
• I can chain three or more commands with | and explain that they run concurrently, not staged through a temp file. (co-15)
• I can choose correctly between <<EOF, <<'EOF', and <<< for a given need. (co-16)
• I can use read -r and explain why the -r flag matters. (co-17)
• I can name at least five of grep/sed/awk/cut/sort/uniq/tr/find/xargs and what each does in one phrase. (co-18)
• I can write a script that reads $1, "$@", and $#, and uses shift to walk its arguments. (co-19)
• I can write a getopts loop with a leading : for silent error handling and explain what ? versus : means in the case branch. (co-20)
• I can register trap handlers for EXIT, INT, and ERR and explain what each one is for. (co-21)
• I can explain why mktemp is safer than a hand-written temp filename. (co-22)
• I can predict what an unquoted glob expands to when it matches nothing, and write the no-match guard that handles it. (co-23)
• I can write a grep -E/sed -E pattern using an anchor, a character class, and a quantifier without looking up the syntax. (co-24)
• I can explain the division of labor between shellcheck (correctness) and shfmt (formatting only). (co-25)
• I can write diff <(cmd1) <(cmd2) from memory and explain what <(...) actually is under the hood. (co-26)
• I can explain, in one sentence, why the Unix pipeline is coupling-vs-cohesion in miniature -- small, highly cohesive tools, loosely coupled through plain text streams. (coupling-vs-cohesion)

Elaborative interrogation & self-explanation

Six why/why-not prompts. Answer each in your own words before opening the model explanation.

E1. Why does the Unix pipeline philosophy favor many small, single-purpose tools (grep, sort, awk, uniq) chained with |, rather than one large tool that does filtering, sorting, and aggregation all at once? Tie your answer to coupling-vs-cohesion.

E2. set -e aborts a script the instant any command fails -- except inside an if condition, a while/until condition, or the left side of &&/||, where a failing command is expected and does NOT trigger the abort. Why does this carve-out exist instead of -e firing everywhere, unconditionally?

E3. Why does getopts's leading-colon "silent mode" (":i:o:h") exist as an option at all, rather than getopts always just printing its own built-in error messages for bad options?

E4. Why does trap 'cleanup' EXIT need to be registered immediately after a resource (like a mktemp file) is created, rather than at the very end of the script, right before it would naturally finish?

E5. Why does an unmatched glob like *.txt expand to the LITERAL, unexpanded pattern string by default, rather than to nothing (zero words) the way a reader might intuitively expect?

E6. shellcheck and shfmt are two entirely separate tools with non-overlapping jobs, run back-to-back in this repo's pre-commit hook. Why not have a single tool do both linting and formatting, the way some other language ecosystems bundle both into one command?

← Previous: Capstone