<aside> 🔤
Module 2 — Variables, Quoting, and Word Splitting. Unquoted variables are the single biggest source of bash bugs in production — this module makes quoting a reflex, not a rule you look up.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 📋
Before you start. You need Module 1: running commands, creating and executing scripts with a shebang and chmod +x, and the fact that bash rewrites your command line before running it (Module 1's restaurant analogy promised details — this module delivers them). Tools: the same terminal and nano; nothing new to install. Keep your ~/bash-course practice directory — we build on it.
</aside>
<aside> 📖
Official docs: Bash manual — Shell Parameters
</aside>
A variable is a named box that holds one piece of text. You create it with a single =:
name="Ada" # create a variable called name, containing the text Ada
And you read it by writing $ in front of the name. When bash sees $name on a command line, it replaces it with the box's contents before running the command — this replacing is called expansion, and it is the first piece of Module 1's "the shell rewrites your order" machinery:
echo "Hello, $name" # bash rewrites this to: echo "Hello, Ada" — then runs it
Two rules that surprise everyone. First: no spaces around the =. Second: the $ is only for reading. Writing $name="Ada" or name = "Ada" are both errors — and the error messages are confusing enough that we will trigger one on purpose in a moment.
Names may contain letters, digits and underscores, and cannot start with a digit. Convention: lowercase names for your script's own variables (retries, logfile), UPPERCASE for system-provided ones (PATH, HOME) — following it prevents you from accidentally overwriting something the system depends on.
<aside> 🧠
Counter-intuitive: why does name = "Ada" fail with name: command not found rather than a helpful "did you mean name=?" — because to bash, spacing is meaning. The very first word of a command line is the command; everything after is its inputs. Write name = "Ada" and the first word is name — so bash goes looking for a program called name (Module 1's PATH search!), fails, and reports it. Bash never guesses your intent from context the way a human reader would. The whole language works like this: where you put spaces and quotes is the grammar.
</aside>
<aside> 🧩
Real-world analogy — labeled jars. A variable is a labeled jar on a kitchen shelf. name="Ada" writes a label and puts something in the jar. $name in a recipe means "whatever is in the jar labeled name, right now" — the cook (bash) opens the jar and pours the contents into the dish before cooking starts. The recipe never contains the jar; it contains what was poured out.
Where the analogy stops working. Jars persist; variables do not. A variable lives only inside the one running shell that created it — close the terminal (or let a script finish — its shell dies, Module 1 C1) and the jar never existed. There is no saved file anywhere. That is also why a variable set in one terminal is invisible in another: two shells, two separate shelves.
</aside>
🧪 Exercise 2.1 — a box, and two classic mistakes
Two of these lines fail on purpose.
name="Ada"
echo "Hello, $name"
name = "Ada" # ← fails: spaces around =
echo "Hello, $Name" # ← "fails" silently: wrong capitalization
${name} — braces for when text touches the variable<aside> 📖
Official docs: Bash manual — Shell Parameters
</aside>