Variables and quoting
Keep data intact as it moves through the shell.
"$var"
20 min read, 25 min lab
operator
Variables are text. Unquoted variables can split on spaces and expand globs. Quoting is the default posture unless you deliberately want splitting.
A backup path includes a space and your script must not split it into two arguments.
Worked command
$ target="/tmp/td script/output file.txt"$ mkdir -p "$(dirname "$target")"$ printf '%s\n' "hello" > "$target"
Do not write `$target` unquoted in file operations.
Quote variables and command substitutions that represent paths or data.
You run rm $files where files="a.txt b.txt". On a standard bash shell, what actually happens?
Show the answer
Correct: B. rm receives two arguments because the value is split on whitespace
Unquoted expansion undergoes word splitting on IFS whitespace, so the shell hands rm two separate arguments. The 'one literal string' answer is exactly what quoting (rm "$files") would give you, which is why it tempts — but unquoted is the unsafe default.
Practice checklist
- Create a variable containing spaces.
- Use it safely with `mkdir`, `printf`, and `cat`.
- Repeat once unquoted in a harmless echo and explain the difference.
Deliverable evidence
- A quoted variable transcript.
- A note explaining word splitting.
shows: The three safety layers of small shell automation — quoting data, null-safe iteration, and guarded action — and how unquoted or unsplit input leaks corruption into the action stage.
does not prove: It is a model, not a guarantee: set -euo pipefail and quoting reduce common failure classes but do not prove a given script is correct or safe on every input.
Commit these to memory, then drill them until recall is automatic.
cue A path variable may contain spaces; you must pass it to a command as a single intact argument
show recall target
"$var"