✂️Module 9 — Parameter Expansion and String Manipulation

read-default: [eu-west-1] — and region is still: []
set-default:  [eu-west-1] — and region is now:  [eu-west-1]
zero is a value: [0]
flag set: [--verbose]  flag unset: []
bash: MUST_EXIST: is required

What to read out of it, line by line: :- supplied the value but left the jar empty (the probe brackets prove it); := supplied and filled the jar — the difference between the two is entirely in that side effect. Line 3 kills a common misreading: 0 is not "empty" — the default did not fire; :- is about missing values, not falsy ones. Line 4 shows :+'s party trick, building a flag out of a variable's mere presence. And the finale: the :? guard printed your message on stderr and — in a script — stops execution dead: the final echo never runs (from a file, the message also gains a line N: prefix). Typed at an interactive prompt, your shell itself survives the failure and the last echo will print — the abort kills scripts, not your terminal. One line, and a whole class of "ran half a deploy with a blank API key" incidents becomes impossible.

The direct answer: "${var:-default}" wherever the value is used, or : "${var:=default}" once near the top to settle it permanently. For read prompts: read -r ans; ans="${ans:-staging}".

Going deeper: lay out the full family as policies — :- read-time, := assign-time, :? required, :+ presence-flag — and the colon rule (with colon: unset or empty; without: strictly unset). The canonical production opener is a block of : "${VAR:?...}" and : "${VAR:=...}" lines that is the script's configuration documentation, self-enforcing.

The details that separate candidates: the ${VERBOSE:+--verbose} idiom for building optional command flags without an if-block; knowing := cannot assign to positional parameters (${1:=x} errors — they're read-only that way); and the subtle honesty that 0 and "0" and a lone space are all values, so the colon family never fires on them — "default" means absent, not falsy.

shortest from back:  backups/db-prod.sql
longest from back:   backups/db-prod
shortest from front: db-prod.sql.gz
longest from front:  db-prod.sql.gz
basename-style: v2.1.0
dirname-style:  /opt/app/releases
version number: 2.14.7

What to read out of it: lines 1–2 are the multi-dot lesson live — same intent ("remove the extension"), two different results; know which you meant. Lines 3–4 happen to match because this path has one slash — with /a/b/c.txt, #*/ yields b/c.txt while ##*/ yields c.txt; the difference reappears the moment paths deepen. The last three lines are the daily bread: pure-bash basename, dirname, and prefix-stripping — no child processes, no quoting adventures, no sed.

The direct answer: "${file%.*}" — strip the shortest match of .anything from the back. For the extension itself: "${file##*.}". For the name without directory and without extension: two steps — name="${file##*/}"; name="${name%.*}".

Going deeper: the multi-dot decision — %.* on app.tar.gz leaves app.tar (usually what you want: one extension off), %%.* leaves app (everything after the first dot gone, which mangles version-dotted names like v2.1.0-notes.txt). And the no-dot edge: ${file%.*} on Makefile returns Makefile unchanged — the pattern must match to cut, which is usually the right failure mode.

The details that separate candidates: explaining # / % by mechanism (front/back, shortest/longest, glob patterns) rather than reciting one memorized incantation; the basename/dirname equivalences and their per-call process cost in loops; and one honest boundary — hidden files like .bashrc fool naive extension logic (${f##*.} yields bashrc), so hostile input deserves a guard.

first dot only: web-01-prod.example.com
every dot:      web-01-prod-example-com
length:         23
first six:      web-01
commas deleted: abc
normalized:     yes

What to read out of it: single vs double slash is first-vs-all — the metrics-name conversion on line 2 (dots to dashes, wholesale) is a real daily task in monitoring pipelines. The length and slice lines read a value by position, which is honest for fixed-format data (the first six characters of a host naming convention) and brittle for anything humans type — prefer pattern-based trims when structure, not position, is what you know. The last line is the production idiom before every case "$answer" in yes) …: normalize once, match simply.

The direct answer: substring expansion — echo "${var:x:y}": from offset x (zero-based), take y characters. Length: "${#var}". Both are pure expansions — the "echo command only" in the question is a hint that no cut/awk is needed.

Going deeper: negative offsets count from the end but need a space — ${var: -3} is the last three characters (without the space, :- is Part A's default operator — a genuinely nasty collision worth naming aloud in an interview). Omitting length takes everything to the end: ${var:5}.

The details that separate candidates: the :--collision detail is the separator on this exact question — it proves you know both operators rather than one; and pairing position-slicing with its honest limits (byte/character subtleties with multibyte text, brittleness on human input) shows judgment, not just syntax.

The direct answer, as a toolbox tour: defaults ${v:-d}; trims ${v#p} ${v##p} ${v%p} ${v%%p} (front/back, shortest/longest, glob patterns); replace ${v/p/r} and ${v//p/r}; length ${#v}; slice ${v:off:len}; case ${v^^} ${v,,} — all in-process, no child commands.

Going deeper: organize by task, the way their answer does — extension handling (trims), sanitizing names for metrics/DNS (global replace), normalizing input (case flips), validation (length + Module 5's =~) — and state the boundary honestly: patterns here are globs; the moment you need real regex captures or multi-line edits, that is sed/awk territory (Module 11), and knowing where the line is is part of the answer.

The details that separate candidates: the performance story (expansion vs $(sed …) in loops — no fork, orders of magnitude in bulk); quoting discipline surviving inside the braces ("${v//p/r}" still gets quoted as a whole); and mentioning that replacement patterns can anchor — ${v/#p/r} start, ${v/%p/r} end — a corner even strong candidates rarely know.

would rename: [meeting notes.txt] -> [meeting_notes.txt]
would rename: [report draft v2.txt] -> [report_draft_v2.txt]

What to read out of it: two renames planned, one file rightly skipped (clean.txt — the continue guard), names shown in probe brackets so any surprise is visible before anything moves. Glob order is alphabetical, hence meeting before report. When the plan reads right, promote the echo to mv -- "$f" "$new" and run once more. This tiny script is the module in miniature: expansion did the string work, and everything around it — glob list, guard, quoting, dry-run — is the earlier track keeping the operation safe.

The direct answer: expansion for one value in a variable — defaults, edge-trims, glob replace, slices, case — in-process and fork-free. sed/awk for streams and files: many lines, regex with captures and classes, field-based work.

Going deeper: the two boundaries that decide it — pattern power (expansion speaks glob only; the moment you need [0-9]+ captures or backreferences, that's regex country) and data location (a variable vs a stream; $(sed …ing a variable…) round-trips through a child process for work bash could do in place). The hot-loop rule from Part B's fleet callout: expansions in loops, external tools on streams.

The details that separate candidates: naming the collision cases where both work and one is clearly better (strip an extension: expansion; edit a config file in place: sed) rather than treating the tools as rivals; and the team-code angle — a chain of three cryptic expansions is sometimes worth trading for one readable awk even at fork cost, because maintenance is also a cost. Judgment, stated as trade-offs, is the interview answer.

Diagnosis. The unguarded empty expansion composing a valid-looking wrong value: myapp:$IMAGE_TAG with the variable absent became myapp: — not an error, a different artifact. Worse than a crash: the failure wore a working costume all the way to production.

Work the steps: reproduce with the variable unset and probe the composed string: printf '[%s]\n' "myapp:$IMAGE_TAG" → [myapp:].

Fix and prevention: the one-liner this module exists for: : "${IMAGE_TAG:?IMAGE_TAG is required (e.g. 2026-09-03-a1b2c3)}" at the top — the message even teaches the format. Optionally stack a shape guard ([[ "$IMAGE_TAG" =~ ^[0-9a-zA-Z._-]+$ ]], Module 5). Fleet rule: any variable that becomes part of an artifact name, path, or URL gets :? — absence must be louder than wrongness.

Diagnosis. B1's multi-dot disagreement, weaponized by a naming change: %%.* eats from the first dot, so api.2026-09-03.log → api — every dated file collapses to the same archive name, and >-style overwrite semantics did the rest. The operator was defensible when names had one dot; the data changed, the greedy trim did not.

Work the steps: run both trims on the new name shape: ${name%.*} → api.2026-09-03 (distinct per day) vs ${name%%.*} → api (collision). One echo each settles it.

Fix and prevention: shortest-match %.* — and state the policy in a comment ("strip ONE extension; dated stems must survive"). Add a collision guard before archiving: [ -e "$out" ] && { echo "refusing to overwrite $out" >&2; exit 1; }. The reusable lesson: greedy trims encode an assumption about dot-count; assumptions about other teams' filenames need guards, not faith.

Diagnosis. Unsanitized data crossing a boundary with its own grammar: the hostname's dots are structure to the metrics system, but content to you. Nothing is broken in bash — the composition simply forwarded hostile characters into a namespace that assigns them meaning (the same disease as Module 2's *-in-data, new costume).

Work the steps: probe the composed name; count dots. Then apply the fix candidate and re-count: h="${HOSTNAME//./-}" → web-01-prod-example-com.

Fix and prevention: sanitize at the boundary, once, in a named helper — metric_safe() { local s="${1//./-}"; printf '%s' "${s// /_}"; } (Module 8's function discipline meeting this module's replaces) — and route every externally-sourced fragment through it. Boundary sanitizers beat scattered fixes: the next hostile character (a space, an underscore policy) changes one function, not forty call sites.

Diagnosis. The hot-loop fork tax (B's fleet callout): three child processes per file × 300k files ≈ a million forks per run, each costing far more than the string work itself. On the laptop sample of 50 files, invisible; on the ingest host, the difference between a minute and the better part of an hour of pure overhead.

Work the steps: measure, don't argue: build a 10k-file test dir, time the loop as written, then the expansion version — name="${f##*/}"; stem="${name%.*}"; clean="${stem//[: ]/_}" — and compare. The ratio settles the review comment with data.

Fix and prevention: expansions inside the loop; if an external tool is genuinely needed (a real regex), restructure so it runs once over the stream (find … | sed …, Module 11's shape) instead of once per file. Codify the review heuristic: $( ) inside a hot loop is a performance smell — justify it or hoist it.