📜Module 10 — Bash Scripting

Hello from a script
I am running as: zaeem

(printed twice — once per way of running it; the username is yours — zaeem, ubuntu, root, whoever you are logged in as)

What to read out of it:

• Both invocations produced identical output, but by different mechanisms: ./hello.sh made the kernel read the shebang and launch bash; bash hello.sh launched bash directly and handed it the file. Knowing both matters — the second is how you run a script you can't (or don't want to) chmod.
• $(whoami) ran inside the script exactly as it does at the prompt (Module 5's command substitution) — a script is just your shell's grammar, saved to a file. Everything you know at the prompt works here.
• The cat > file <<'EOF' … EOF you've been pasting since Module 6 is a heredoc: it feeds the lines up to EOF into the file. The quotes around 'EOF' stop the shell expanding $(whoami) while writing the file — you want that expansion to happen when the script runs, not when it's created. Unquoted EOF would have baked in your current username. A quoting subtlety with real consequences.

Script name: ./args.sh
First argument: alpha
All arguments: alpha beta gamma
Number of arguments: 3

then, with no arguments:

Script name: ./args.sh
First argument: 
All arguments: 
Number of arguments: 0

What to read out of it:

• With arguments, $1/$@/$# reported exactly what you passed. With none, $1 and $@ came back empty — no error, no warning. That silent emptiness is the single most common source of script bugs, and $# (count zero) is how a well-written script detects it before doing damage.
• A script that acts on $1 without checking $# first will, run with no argument, operate on the empty string — deleting "", deploying "", connecting to "". Part B's first job is to make that impossible.

The shebang (#!/usr/bin/env bash or #!/bin/bash) is the script's first line; the kernel reads its #! marker when you execute the file by path and launches the named interpreter to run the script. #!/usr/bin/env bash locates bash via PATH (portable across systems where bash lives in different places); #!/bin/bash hard-codes the location (predictable, common on Linux). To bash itself the line is a comment.

The details that separate candidates: that it only takes effect when running ./script (not bash script, which names the interpreter directly); the env vs hard-path trade-off (portability vs predictability); and the failure mode — a #!/bin/sh shebang runs the script under dash on Debian/Ubuntu, breaking bash-only syntax (Module 1's dash lesson, now with teeth).

Pass them after the script name (./deploy.sh web-01 v2); access them inside as positional parameters: $1, $2, … for individual arguments, $@ for all of them, $# for the count, $0 for the script name. Always double-quote them ("$1", "$@") to survive spaces. $@ inside double quotes uniquely expands to each argument as its own word — the correct idiom for forwarding arguments to another command. (Turing's variant: cwd="$(pwd)" — command substitution into a variable, Module 5.)

The details that separate candidates: "$@" vs "$*" (the former keeps arguments separate, the latter joins them into one string — the B-part interview question); shift to consume arguments in a loop; and validating $# before use, because unsupplied parameters expand to empty strings silently.

/etc/hostname is a regular file
/etc is a directory
/nope does not exist

What to read out of it:

• Three inputs, three branches — the script decided rather than blindly acting. Every one of those -f/-d/-e tests is Module 3's stat metadata, exposed as a yes/no.
• The quoting of "$target" is not decoration: run ./check.sh with no argument and it still works (reports the empty string "does not exist") because the variable is quoted — unquoted, [[ -f $target ]] with an empty target becomes [[ -f ]], which tests whether the string "-f" is non-empty (always true), silently misrouting. The quotes are load-bearing.

checking web-01
checking web-02
checking db-01
found log: a.log
found log: b.log
line: first
line: second
line: third

What to read out of it:

• The glob loop found exactly the .log files and skipped c.txt — bash expanded *.log to real filenames before the loop ran (Module 5's globbing, in a loop). Note it did not run ls; the glob is the list.
• while IFS= read -r processed each line intact. This exact idiom — over a file, or over a command's output via a pipe — is how you iterate log lines, config entries, or a list of hosts in a script. Memorize its shape; the IFS= … -r looks like noise but each piece prevents a specific real bug.

It is now 14:32:07
4 is even
7 is odd

(the time is your machine's own)

What to read out of it:

• timestamp returned data — captured with $(...) into now. is_even returned status — tested with if. Two functions, two channels, cleanly separated. This is the pattern for every helper you'll write.
• is_even has no echo and no return — its status is simply that of its last command, the (( )) test, which is exactly the yes/no you want. That's idiomatic bash: a predicate function is just a test whose success is the answer.

[ is the POSIX test command (a program/builtin): works everywhere, but needs careful quoting and mishandles empty/unset variables. [[ ]] is bash's keyword test: safer with variables, supports &&/|| and pattern matching (== with globs), no word-splitting surprises — the default for bash scripts. (( )) is arithmetic evaluation: for numeric comparisons ((( n > 3 ))), where you use >/</== on numbers and don't need $ on variables inside.

The details that separate candidates: choosing [[ ]] for strings/files and (( )) for arithmetic as a habit; knowing [ needs spaces around every token because it's literally a command receiving arguments; and the portability note — a script targeting POSIX sh (a #!/bin/sh shebang) cannot use [[ ]] and must fall back to [ ], which is why [ ] still matters.

Define with name() { commands; }, call as name arg1 arg2 (arguments become the function's $1, $2, $@). Two return channels: status via the exit code (last command's, or return N where N is 0–255) — test it with if name; then; data via echo/printf captured with result="$(name)". Use local var inside to avoid polluting the caller's variables.

The details that separate candidates: the status-vs-data distinction stated crisply (and the classic bug of return-ing a large number, which wraps mod 256); local for hygiene; and that a predicate function needs neither echo nor return — its last test's status is the answer, the idiomatic bash predicate.

Both expand to all positional parameters; the difference appears when quoted. "$@" expands to each argument as a separate word — "$1" "$2" "$3" — preserving boundaries, so it's the correct way to forward arguments to another command. "$*" joins all arguments into a single word separated by the first character of IFS (a space by default) — useful when you genuinely want one string. Unquoted, $@ and $* behave identically (both word-split), which is why the quoted forms are what matter.

The details that separate candidates: "the difference only shows when quoted" — the whole point; a concrete use for each ("$@" to pass args through, "$*" to build a log message); and connecting it to the loop for arg in "$@" being the safe way to iterate arguments including those with spaces.

step 1
./loose.sh: line 3: cd: /nonexistent-directory: No such file or directory
step 2 (ran anyway — on the WRONG directory!)
loose exit: 0
---
step 1
./strict.sh: line 4: cd: /nonexistent-directory: No such file or directory
strict exit: 1

What to read out of it:

• The loose script's horror, in one line: cd failed, and step 2 ran anyway — but now in whatever directory the script started in, not the intended one. Imagine step 2 was rm -rf ./*. This is precisely how "the cleanup script deleted the wrong directory" postmortems begin (Module 5's Ticket 2, mechanism now named).
• The loose script even exited 0 — reporting success while having done the wrong thing. Automation downstream trusts that 0.
• The strict script stopped at the failure and exited 1 — loud, immediate, honest. Everything that would have run on the bad state simply didn't. set -euo pipefail earned its place at the top of the file in this one comparison.

working in /tmp/tmp.aB3xK9mQ2r
scratch.txt
done — the temp dir will be gone after this exits

(the final ls does not show the script's temp dir — it was removed on exit)

What to read out of it:

• The script created a temp dir, used it, and it was gone by the time the next command ran — the trap fired on exit. Crucially, this would have happened even if a command inside the script had failed and set -e aborted it: the trap runs on the error-exit too. Cleanup you can't forget.
• mktemp -d gave a random unique name (/tmp/tmp.aB3xK9mQ2r) — never a hard-coded /tmp/mytemp, which two simultaneous runs would collide on. Unique temp names plus a cleanup trap is the standard safe pattern for any script that needs scratch space.

created /tmp/myapp/app.conf
/tmp/myapp/app.conf already exists — leaving it
./setup.sh: line 3: 1: usage: setup.sh APPDIR

What to read out of it:

• First run created; second run noticed and left it — same end state, no error, no duplicate. That's idempotence: the second run confirmed the state rather than blindly re-acting.
• The mkdir -p never complained the directory already existed (that's -p's whole job), and the [[ ! -f ]] guard protected the config from being overwritten on the re-run.
• The no-argument run hit ${1:?...} and aborted with your usage message and a non-zero exit — the loud, immediate failure that a required-input guard is for. Compare Module 5's silent form-letter disaster; this is the cure, one line at the top.

set -e aborts the script the moment any command fails (non-zero) instead of continuing on a broken state. set -u aborts on use of an unset variable; set -o pipefail makes a pipeline fail if any stage fails (not just the last); set -x (the extra letter in LabEx's -euxo) traces each command as it runs — a debugging aid. Together set -euo pipefail is the standard strict-mode prologue.

The details that separate candidates: the "when it bites" honesty — set -e is suppressed for commands in if/&&/|| (correctly), doesn't fire in some subshell/function contexts, and can surprise with commands that "fail" normally (like grep finding nothing, Module 6's exit 1); the fix (grep … || true when a no-match is acceptable); and the mature framing that strict mode is a high-value safety net you combine with explicit checks, not a substitute for them.

Empty check: [[ -z "$var" ]] (true if empty), [[ -n "$var" ]] (true if non-empty). Parameter expansion handles defaults and requirements: ${VAR:-default} uses default if VAR is unset/empty (without changing VAR); ${VAR:=default} also assigns it; ${VAR:?message} aborts with the message if VAR is unset/empty — the required-argument guard; ${VAR:+alt} uses alt only if VAR is set.

The details that separate candidates: reaching for ${1:?usage…} to validate required arguments instead of hand-writing an if-block; knowing :- vs := (one assigns, one doesn't); and pairing empty-checks with set -u so that unintended unset variables abort while intended defaults are handled explicitly — the two working together is the robust pattern.

+ name=web-01
+ greeting='deploying to web-01'
+ echo 'deploying to web-01'
deploying to web-01
+ set +x
done

What to read out of it:

• Each + line is what bash ran after expansion — you can see $name became web-01 inside greeting before echo ever ran (Module 5's expansion order, made visible). This is exactly the view you need when a variable "has the wrong value": the trace shows what it actually expanded to.
• The plain lines without + are the program's real output (deploying to web-01, done); the + lines are the trace, which bash writes to stderr — so ./trace.sh 2>/dev/null would show only the real output, a handy way to separate the two.
• After set +x, tracing stopped — echo "done" ran untraced. Scoping the trace to the suspect region keeps the signal readable.

In buggy.sh line 2:
echo "checking $file"
               ^---^ SC2154 (warning): file is referenced but not assigned (for output from commands, use "$(file ...)" ).

In buggy.sh line 3:
rm -rf $dir/
       ^---^ SC2115 (warning): Use "${var:?}" to ensure this never expands to / .
       ^--^ SC2154 (warning): dir is referenced but not assigned.
       ^--^ SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean:
rm -rf "$dir"/

What to read out of it:

• Every finding is a bug this track named: SC2154 — a variable used but never set (both $file and $dir, Module 5's silent-empty-expansion); SC2115 — rm -rf $dir/ could expand to rm -rf / if $dir is empty (Module 5's Ticket 2 catastrophe, caught statically!); SC2086 — the missing double-quotes that cause word-splitting. shellcheck found in one second what took two modules to teach.
• The Did you mean: rm -rf "$dir"/ is a concrete fix suggestion — and ${var:?} (Part C's guard) is exactly what SC2115 recommends to make the empty-expansion impossible. The linter is teaching the same lessons, enforced.
• Running shellcheck on every script before it ships is not optional discipline for a professional; it is the cheapest bug-prevention available. Wire it into CI and the class of bug simply stops reaching production.

no crontab yet for this user

(or your existing schedule, if any)

What to read out of it — decode each line:

• 30 3 * * * — minute 30, hour 3, every day: 03:30 daily. Note the >> …log 2>&1 (Module 5) — this author redirects both streams to a log, escaping cron's silent-failure trap. Good hygiene, visible in the schedule.
• */10 * * * * — every 10 minutes, all day. The */N step syntax is the one worth memorizing; it appears in every real crontab.
• 0 0 1 * * — minute 0, hour 0, day-of-month 1: midnight on the 1st of every month. The two day fields (day-of-month and day-of-week) are a classic confusion — when both are set to specific values, cron runs when either matches, a genuinely surprising rule worth knowing before you write 0 0 13 * 5 expecting "Friday the 13th only".
• The absolute paths (/usr/local/bin/…) are deliberate: cron's bare PATH wouldn't find these by name. Every command in a crontab should be an absolute path, for exactly the reason Module 5's Ticket 1 taught.

cron runs jobs at exact scheduled times and assumes the machine is always on — a job scheduled for 03:00 on a powered-off laptop simply never runs (the time passed while off). anacron is designed for machines that aren't always running (laptops, workstations): it works in days, not clock times, and runs a job if it's been more than N days since it last ran, catching up on missed jobs after boot. So cron for always-on servers with precise timing; anacron for periodic jobs that must eventually run on intermittent machines.

The details that separate candidates: the always-on assumption of cron as the key difference (and its consequence — missed jobs are simply skipped, not caught up); knowing many desktop distros run the daily/weekly /etc/cron.* jobs via anacron for exactly this reason; and that on modern systems systemd timers with Persistent=true cover both cases (precise scheduling and catch-up), which is where new automation increasingly lives (Module 11).

The published banks touch cron lightly (InterviewBit's cron-vs-anacron, GeeksforGeeks mentioning crontab -e) and essentially skip script debugging — yet "your cron job isn't running, how do you debug it?" is a live-interview staple, and the answer is pure Module 5 plus this Part: check the job actually fired (cron's own log, /var/log/syslog or journalctl), check PATH and environment (cron's are minimal — absolute paths, set vars explicitly), check where output went (redirect to a log), and reproduce by running the script with cron's environment (env -i to strip it down). Being able to walk that debugging tree — and to write set -x and shellcheck into your workflow — is what the interview is really testing when it asks a scheduling question.

Ticket text: "Our backup script rm -rf $BACKUP_DIR/old cleared a production directory when BACKUP_DIR wasn't set. Rewrite it to be safe, and explain each guard."

Worked answer — the offending line plus its whole context needs the module's defenses, so present the rewritten prologue and reasoning: start with #!/usr/bin/env bash and set -euo pipefail (so an unset BACKUP_DIR aborts instead of expanding to empty — the direct cause); require the variable explicitly with BACKUP_DIR="${BACKUP_DIR:?BACKUP_DIR must be set}" (loud failure, not silent /); quote every use (rm -rf "$BACKUP_DIR/old" — SC2086); and before the destructive line, validate the target is what you expect ([[ -d "$BACKUP_DIR/old" ]] || { echo "nothing to clean"; exit 0; }). Run shellcheck on the result — it should come back clean, having flagged exactly the SC2115/SC2086 that caused the incident. The explanation to send: the incident was an unset variable meeting an unquoted rm -rf; set -u + ${VAR:?} + quoting makes that specific catastrophe impossible, and shellcheck in CI stops it reaching production again.

Ticket text: "We need a script that takes a list of hostnames, checks each is reachable, and reports a summary — pass/fail count and which hosts failed. Must be safe to run repeatedly and from cron."

Worked answer — compose the whole module: strict-mode prologue; accept hosts as arguments ("$@") with a usage guard ([[ $# -gt 0 ]] || { echo "usage: $0 host..."; exit 1; }); a for host in "$@" loop (quoted, so spaces in an argument can't split it); inside, a check whose exit status is the pass/fail (if ping -c1 -W2 "$host" &>/dev/null; then …); accumulate counts in variables and failed hosts in an array; print a summary at the end; exit non-zero if any failed (exit "$fail_count"-style, so cron/CI can detect it). It's idempotent by nature (checking is read-only), and cron-safe if you use the absolute path to ping and redirect output. The design points to name: the loop's status-based check (Module 8's exit codes), the meaningful exit code for automation to consume, and the summary that makes the output actionable rather than a wall of per-host lines.

Ticket text: "The log-rotation cron job 0 1 * * * rotate-logs.sh hasn't run successfully since the 3rd, but nobody noticed until /var filled up. Debug it and prevent recurrence."

Worked answer — walk the debugging tree from Part D. Did it fire? Check the cron log (grep CRON /var/log/syslog or journalctl -u cron) for the 01:00 runs — if they fired, it's the script failing; if not, it's the crontab. Why did it fail? The classic: rotate-logs.sh was written and tested in a terminal (full PATH) but the crontab entry uses a bare name rotate-logs.sh that cron's minimal PATH can't find — command not found, silently. Confirm by reproducing with cron's environment: env -i /bin/sh -c 'rotate-logs.sh'. Fix: absolute path in the crontab (/usr/local/bin/rotate-logs.sh), redirect output to a monitored log (>> /var/log/rotate.log 2>&1), and add strict mode to the script so a partial failure exits non-zero. Prevent recurrence: a dead-man's-switch monitor that alerts if the job stops reporting success — because the root failure here wasn't the bug, it was that nothing noticed for three weeks. The postmortem's lesson is monitoring the absence of success, not just adding a log.

Ticket text: "Deploys are currently ten commands an engineer pastes by hand, and they make mistakes. Make it a script anyone can run as deploy.sh <app> <version>, safely."

Worked answer — the synthesis ticket. Structure: strict-mode prologue; validate the two required arguments up front (app="${1:?usage: deploy.sh APP VERSION}"; version="${2:?usage: deploy.sh APP VERSION}"); wrap logical steps in named functions (fetch_release, stop_service, swap_symlink, start_service, verify) so the script reads like the runbook it replaces and each step is independently testable; use a trap to clean up (and ideally to roll back — repoint the symlink to the previous release, Module 3's deploy pattern) if any step fails; make each step idempotent where possible; check each critical command's success explicitly rather than trusting set -e alone for the destructive ones; and log what it's doing. Run shellcheck before it ships. The framing to deliver: this converts error-prone human pasting into a reviewed, tested, repeatable artifact with a rollback path — which is the entire reason scripting exists, and the on-ramp to configuration management (the Ansible track) that does this across a fleet.