5️⃣Module 5 — The Shell, Properly

web-01
deploying to web-01
target

What to read out of it:

• The $ is the whole trigger: with it, the shell substituted; without it, the literal word passed through. Programs never see $target — they see whatever it expanded to, which is why debugging starts with "what did the shell actually pass?"
• This variable lives only in this shell. Open a second terminal and echo $target — empty. Not shared, not saved: closing the terminal deletes it. Persistence is A3's business.

bash: name: command not found

What to read out of it:

• With spaces, the shell read this as: run a command called name with arguments = and web-01. Word splitting — Module 2's lesson — applied before any notion of "assignment" could. There is no special assignment parser watching for your intent; there is only the grammar.
• File this error's shape away: command not found naming something you meant as a variable is nearly always the spaces-around-equals slip.

child sees: 
child sees: hello

What to read out of it:

• Line one: the child expanded $greeting to nothing — the variable existed only in the parent. Line two: after export, the copy travelled. That empty first line is the unset-variable silence from A1's analogy, live.
• Note the single quotes around the child's command — they kept the parent from expanding $greeting prematurely (Part B explains exactly this). The child did its own expansion, which was the point of the experiment.

nano

What to read out of it:

• EDITOR is a real convention: programs that need to open an editor for you (git, crontab, visudo) launch whatever it names. You just configured every future tool at once — the point of environment variables in one example.
• Open a new terminal and check echo $EDITOR there too: the checklist ran, the setting held. That round trip — edit, source, verify, new-terminal verify — is the standard ritual for every .bashrc change.

total 8
drwxrwxr-x  2 zaeem zaeem 4096 Sep  2 16:02 ./
drwxr-x--- 15 zaeem zaeem 4096 Sep  2 16:02 ../
ll is aliased to `ls -alF'

What to read out of it (owner, link counts and dates are your machine's own):

• -alF decoded with four modules of vocabulary: all files (dotfiles included), long format, and -F appends type markers — / for directories. The . and .. entries from Module 2, present as promised.
• type answered "what IS this name" — for an alias, it shows the expansion. Module 1 taught type for builtins vs programs; aliases are the third answer it gives.

Named values a process receives as a snapshot copy from its parent at launch — the standard configuration channel of Unix. Set with name=value, promoted into the environment with export, inspected with env/printenv. The system's own residents: PATH (command search), HOME, USER, SHELL, LANG. Modern operations run on them — database URLs, API keys, log levels — because they configure a process without touching files or code.

The details that separate candidates: the copy-at-launch semantics and both one-way consequences (parent changes don't reach running children — hence restart-after-config-change; child changes don't reach the parent — hence cd is a builtin); plus one security note: environment variables of a process are visible to root and, historically, to more — secrets belong in secret stores, with env vars as the delivery leg.

Defines a personal shorthand the interactive shell expands before running: alias ll='ls -alF'. Listed with alias, removed with unalias, made permanent in .bashrc. Good for abbreviating your own high-frequency commands; inspected with type name when behaviour surprises.

The details that separate candidates: the two boundaries — aliases don't exist in scripts (non-interactive shells skip them) and don't travel to other machines; and the safety-alias critique: alias rm='rm -i' trains muscle memory that betrays you on every machine without it — seniors mention this unprompted.

ls: cannot access 'release': No such file or directory
ls: cannot access 'notes.txt': No such file or directory
-rw-rw-r-- 1 zaeem zaeem 0 Sep  2 16:05 'release notes.txt'

What to read out of it (owner and dates are your machine's own):

• The unquoted $file expanded to release notes.txt and was then split: ls received two arguments, and Module 2's two-error signature appeared — same disease, now with the mechanism fully visible: expansion first, splitting second, command last.
• The quoted version delivered one argument. Note ls itself quoting the name in its output — modern coreutils flags awkward names back at you.
• Re-read Module 2's D3 with today's eyes: everything there was this section, experienced before it could be explained.

logged in as zaeem
logged in as $user
it costs $5

What to read out of it:

• Same line, three treatments: expanded, verbatim, and selectively-escaped. The decision procedure, permanently: want expansion → double quotes; want nothing touched → single quotes; want one exception → backslash it inside double quotes.
• Line two is not a failure — printing literal $user is exactly what documentation, config templates, and code destined for other interpreters need.

app.log db.log
app.log db.log notes.txt release notes.txt
ls: cannot access '*.pdf': No such file or directory

What to read out of it:

• The echos display the post-expansion command line — the exact arguments any command in that position would receive. echo + glob is the free dry run for every rm/mv/cp you will ever aim at a pattern; use it before the real thing, always.
• Line two carries a subtle horror: release notes.txt (B1's file) appears as two space-separated words indistinguishable from separate names. Expansion output is a split word list, not a display listing — globs and spaced filenames interact viciously, another reason the professional convention avoids spaces in names.
• The failure line: no match, so ls received the literal string *.pdf and looked for that file. Read the quotes in the error — they are showing you exactly what it received.

* (any run), ? (one character), [a-z]/[abc] (one from a set) — written in any argument position: ls *.log, rm report-2026-0?.csv, cp deploy-[ab].conf backup/. The shell — not the command — expands the pattern into matching filenames before execution; dotfiles are excluded unless the pattern itself starts with a dot.

The details that separate candidates: stating who expands (the shell), with a consequence or two — quoting disables matching; empty matches pass the literal pattern through; huge matches overflow the argument list — and the dry-run habit of previewing any destructive glob with echo first. Recall-level answers list the symbols; systems-level answers explain the mechanism.

Published question banks barely touch quoting — none of the sets used in this track ask about single-versus-double quotes directly. Yet quoting failures are a favourite live probe: interviewers show a broken rm $file or an awk one-liner mangled by double quotes and ask "why?". Prepare by being able to narrate B1.1's failure — expansion, then splitting, then execution — without notes; that narration is the answer to every quoting question they can construct.

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
date is /usr/bin/date
bash: hello.sh: command not found
hello from my first script

(Your PATH will differ in detail — tool installers love adding entries; type date may say hashed if you've run date this session, Module 1's footnote.)

What to read out of it:

• Walk date's lookup along your own PATH string, directory by directory, to /usr/bin — make the mechanism concrete once and it is yours forever.
• The failure is the PATH working as designed: ~/perms is not on the route, so the bare name does not exist, while ./ bypasses the route entirely with an explicit address. command not found for something you can see now has a precise diagnosis: right file, unlisted directory.

notes.txt
0
ls: cannot access 'missing.txt': No such file or directory
2
created
cp: cannot stat 'missing.txt': No such file or directory
copy failed

What to read out of it:

• 0 then 2: the invisible verdict, made visible. One catch worth learning now: $? holds only the most recent verdict — even your echo $? overwrote it (with echo's own 0). Capture it immediately if you need it: status=$?.
• The chains: && fired the success branch; on the failing cp, && was skipped and || fired. The a && b || c idiom reads like if/else and mostly behaves like one (the true conditional arrives in Module 10).
• ls chose 2 for "serious trouble" — each program defines its own nonzero vocabulary; only 0 has a universal meaning.

PATH is the colon-separated, ordered directory list the shell walks to resolve bare command names — first match wins, misses everywhere mean command not found. It is why installed-but-elsewhere tools "don't exist", why ./script is needed for the current directory (which is excluded, deliberately, for security), and why the same command name can resolve differently for different users or in cron. Extended per-user via .bashrc (export PATH="$HOME/bin:$PATH").

The details that separate candidates: search order as an attack/override surface (prepending a directory shadows system commands — used both by installers and by attackers); the security story for excluding .; and the operational classic — cron and other non-interactive contexts carry a minimal PATH, which is why "works in my terminal, fails in the scheduler" is a PATH bug until proven otherwise.

No published set used in this track asks about exit codes directly — and yet $?, &&/||, and "how does your pipeline know the deploy failed?" come up in nearly every live DevOps interview, usually inside a scripting or CI question. Be able to state cold: 0 is success and the only universal code; $? holds the last verdict and is immediately perishable; 126 vs 127; and that automation trusts codes, not output — then connect it to set -e when scripting comes up. The absence from question banks makes fluency here more distinguishing, not less.

ls: cannot access 'missing.txt': No such file or directory
notes.txt
notes.txt
ls: cannot access 'missing.txt': No such file or directory
ls: cannot access 'missing.txt': No such file or directory
notes.txt
2

What to read out of it:

• One command, two files, cleanly separated: results in out.txt, complaint in err.txt. This is how every scheduled job should be plumbed (a Module 11 refrain).
• In the merged file, the error may appear before the result — the two streams buffer differently, so interleaving order is not guaranteed. Real logs have this texture; timestamps, not position, order events.
• The discard line printed nothing — but $? still says 2. Silencing a stream does not silence the verdict: automation built on exit codes keeps working with output thrown away. Discard output only when you have decided the code is what you act on.

228
total 808
lrwxrwxrwx 1 root root     39 May  8 16:23 README -> ../../usr/share/doc/systemd/README.logs
-rw-r--r-- 1 root root  45911 Sep  2 14:22 alternatives.log
drwxr-xr-x 2 root root   4096 Sep  2 14:22 apt
-rw-r--r-- 1 root root  61229 Apr 10 02:20 bootstrap.log
20

What to read out of it (counts are your machine's own):

• Every command here was taught modules ago; the pipe is the only new ingredient, and suddenly questions ("how many?", "just the top") become one-liners. This is the inflection point of the whole track: from running commands to composing them.
• Note head receiving ls -l's output mid-production and cutting it off at five lines — ls is then simply terminated early. Concurrency, visible.
• If the last line instead printed tail: cannot open ... No such file or directory and then 0: nothing is broken — bash writes the history file at logout, so a brand-new account has not created one yet. Log out, back in, and it exists. (Note wc still printed a count: the pipe carried tail's empty stdout while the error took the stderr bypass.)
• Modules 6 and 7 supply the great pipeline citizens — grep, sort, awk — and this section is why they compose.

there are 7 files here
notes-2026-09-02.txt

What to read out of it (count and date are your machine's own):

• A pipeline ran inside a string, its answer landing mid-sentence. Substitution composes with everything — including pipes.
• The dated-backup idiom is used verbatim across the industry: timestamped copies before risky changes, built from Module 2's cp, Module 1's date, and today's $(...). You now construct file names from live data — carefully quoted.

| connects one command's stdout to the next command's stdin through a kernel buffer — no intermediate file, no disk. It is the composition operator of the small-tools philosophy: ls -l | grep conf | wc -l chains three single-purpose tools into an answer. Stages run concurrently, memory use stays flat regardless of data volume, and stderr bypasses the pipe entirely, arriving at the terminal.

The details that separate candidates: concurrency (not batch hand-off) and its corollary — a stalled consumer blocks the producer; stderr's separate path; and the exit-code subtlety: a pipeline's status is the last command's, so failing-cmd | tee log reports success — the pipefail fix belongs in every professional script (Module 10 installs it).

Re-aiming a process's standard streams before it runs: > stdout to a file (truncating), >> appending, 2> stderr, 2>&1 stderr to stdout's current target, < file as stdin, /dev/null as the discard. Canonical job form: command >> /var/log/job.log 2>&1. The shell sets up all plumbing left-to-right before executing, which is why 2>&1's position matters.

The details that separate candidates: the truncate-before-run trap (sort f > f destroys f); the > log 2>&1 vs 2>&1 > log ordering, explained via the snapshot mechanism rather than recited; and separating streams on purpose — results parseable, errors visible — as a design habit, not an exam answer.

Not asked directly in any recent published set consulted — but it appears inside the answers to scripting questions everywhere ("store the output of a command in a variable"). Own the one-liner: $(cmd) captures output, trailing newline stripped, quote it or it word-splits. Backtick syntax cmd is the legacy spelling — recognize it in old scripts, write the modern form.

Ticket text: "Our scheduled backup job logs backup-tool: command not found. Pasting the identical line into a terminal works perfectly. The tool is installed in /opt/backup/bin. Explain and fix."

Worked answer: the terminal shell read .bashrc, which prepends /opt/backup/bin to PATH; the scheduler's non-interactive shell reads no such file and carries a minimal PATH — so the bare name resolves in one context and not the other. Same command, different universes of names. Prove it: log echo "$PATH" from inside the job and compare. Fix, in order of preference: call the tool by absolute path (/opt/backup/bin/backup-tool) — automation should not depend on name resolution; or set PATH=/opt/backup/bin:/usr/bin:/bin explicitly at the top of the job. The general law, worth writing on the wall: interactive convenience (PATH edits, aliases, .bashrc) does not exist in automation.

Ticket text: "A script ran `rm -rf ${STAGING_DIR}` and deleted the working directory it was launched from, not the staging area. STAGING_DIR is set in the engineer's .bashrc and 'has always worked'. Postmortem the mechanism and the guards."*

Worked answer: mechanism — the script ran non-interactively, read no .bashrc, so STAGING_DIR was unset; the expansion produced nothing, leaving plain rm -rf *, which faithfully wiped whatever directory the script happened to be launched from (A1's form letter, sent with its blank unfilled). Had it been written rm -rf $STAGING_DIR/, the empty expansion would have produced rm -rf / — refused by GNU rm's --preserve-root failsafe, but a script should never get to lean on that final guard. Guards, all of which belong in Module 10's script prologue: quote and require the variable ("${STAGING_DIR:?not set}" — the :? form aborts with a message when unset; meet it properly in Module 10), set -u to make unset expansion fatal, never end an rm path with a bare expansion, and dry-run with echo in review. The .bashrc dependency was the root cause: configuration for automation lives in the automation, never in a human's dotfiles.

Ticket text: "Runbook line: deploy.sh 2>&1 > /var/log/deploy.log. The deploy failed; the log contains only the success chatter, and the errors were lost with the closed terminal. Why?"

Worked answer: plumbing order. Left to right: 2>&1 first — aim stderr at stdout's current target, the terminal; then > /var/log/deploy.log — move stdout to the log, stderr staying where it was pointed. Result: chatter logged, errors to a terminal nobody kept. The fix is transposition: deploy.sh > /var/log/deploy.log 2>&1 (stdout to log first, then stderr to the same place). Better runbook practice: split them — >> deploy.log 2>> deploy.err — so failures are findable without scrolling chatter, and use >> so reruns never truncate history. The interviewable sentence: redirections are snapshots evaluated left to right, not live links.

Ticket text: "An engineer 'cleaned up' a data file with sort data.csv > data.csv and the file is now zero bytes. They insist sort must be buggy. Explain, recover, prevent."

Worked answer: not sort's doing — the shell's. Before sort launched, the shell opened data.csv for stdout redirection, truncating it to zero; sort then read an already-empty file and correctly wrote nothing. The program never had a chance to see the data. Recovery: backups or re-generation — the bytes are gone (Module 3's shredder rule). Prevention: write to a new name and swap on success — sort data.csv > data.sorted && mv data.sorted data.csv — which also leaves the original intact if sort fails (the && earning its keep); Module 7 adds sort -o data.csv data.csv, sort's own safe in-place flag, and the general lesson stands: the shell sets up all plumbing before the command runs.