Variables and Quoting in Bash
Bash variables are untyped, dynamically created name-value pairs; assigning one is as simple as name=value with no spaces around the =. Variables are expanded (substituted) using $name or ${name}, and how that expansion behaves — whether whitespace splits it into multiple words, whether glob characters like * get expanded — depends entirely on quoting. Quoting is not cosmetic in Bash; it is the mechanism that controls word splitting and pathname expansion, and getting it wrong is the single most common source of subtle scripting bugs, from broken filenames with spaces to unintended command injection.
Cricket analogy: Naming a player's stats variable is as simple as writing runs=87 with no spaces, and calling it back with $runs pulls the value; but if you don't quote a scorecard entry properly, a name like 'M S Dhoni' can get split into three separate words during data entry, corrupting the record.
Assignment and expansion basics
name=value assigns without a $; using $name in an assignment would instead try to expand an existing variable. Bash performs no automatic type conversion — every variable is stored as a string, even when it holds digits, and arithmetic must go through ((...)), $((...)), or let. ${name} (braces) is preferred over $name when concatenating with adjacent text, e.g. ${file}.bak, because $file.bak would try to expand a variable literally named file followed by the literal text .bak, which happens to work by coincidence, but ${file}_bak is required to avoid Bash trying to expand a variable called file_bak.
Cricket analogy: Writing score=250 (no $) records the total, while $score later reads it back; appending text like ${score}runs needs braces because $scoreruns would look for a nonexistent variable named 'scoreruns' — and net run rate math still needs $((...)) since Bash stores even '250' as plain text.
name="Alice"
count=5
greeting="Hello, ${name}! You have ${count} new messages."
echo "$greeting"
# Arithmetic requires explicit context
total=$((count + 10))
echo "Total: $total"
# Readonly and exported variables
readonly MAX_RETRIES=3
export LOG_LEVEL="debug"
# Unsetting a variable
unset greetingDouble quotes vs single quotes vs no quotes
Double quotes ("...") suppress word splitting and pathname (glob) expansion but still allow variable expansion ($var), command substitution ($(...)), and arithmetic expansion. Single quotes ('...') suppress everything — no expansion of any kind occurs inside them, making them ideal for literal strings like regular expressions or passwords you don't want the shell to touch. Leaving a variable unquoted lets the shell word-split it on IFS (whitespace by default) and glob-expand any *, ?, or [...] characters it contains, which is almost always a bug when the variable might hold a filename with spaces or special characters.
Cricket analogy: Wrapping a player name in double quotes like "$player" still lets it expand to 'Virat Kohli' but keeps it as one entry, while single quotes around a literal regex like '^MS Dhoni' block all expansion; leaving $player unquoted risks the shell splitting it into 'Virat' and 'Kohli' as two arguments.
file="my report.txt"
# BROKEN: unquoted expansion splits into two words
rm $file # tries to remove files named 'my' and 'report.txt'
# CORRECT: quoted expansion preserves it as one argument
rm "$file"
# Single quotes: nothing is expanded
echo '$file is not expanded here'
# Double quotes: variable and command substitution still work
echo "Current user: $USER, date: $(date +%F)"
# grep pattern with regex metacharacters — must be single-quoted
grep '^[0-9]\{3\}-[0-9]\{4\}$' phonebook.txtUnquoted variable expansion is the classic Bash footgun. for f in $(ls *.txt); do rm $f; done breaks on filenames containing spaces or glob characters, and can even be exploited maliciously if a filename is crafted like -rf / combined with a careless command. Always default to quoting variable expansions ("$var") unless you deliberately want word splitting, and prefer find ... -exec or arrays over parsing ls output at all.
ShellCheck (shellcheck.net, or the shellcheck package) is a static analysis tool that catches unquoted-variable bugs, deprecated syntax, and dozens of other common scripting mistakes before you ever run the script. Running it on every script you write is considered standard practice in professional Bash development, similar to running a linter on any other language.
Parameter expansion and default values
Bash's ${var:-default} syntax substitutes default if var is unset or empty, without modifying var itself, while ${var:=default} does the same but also assigns default back into var. ${var:?message} exits with an error message if var is unset, useful for validating required inputs early in a script. These parameter expansions let you write defensive scripts without verbose if statements for every variable.
Cricket analogy: ${venue:-Wankhede} falls back to Wankhede Stadium if venue is unset without changing it, while ${venue:=Wankhede} also assigns that default back into venue; ${captain:?Captain required} halts a script with an error if captain was never set, catching a missing lineup entry early.
# Use a default if TARGET_DIR isn't set
dir="${TARGET_DIR:-/tmp/output}"
# Require an argument or exit with a clear error
input_file="${1:?Usage: $0 <input_file>}"
# String length and substring parameter expansion
name="production"
echo "${#name}" # 10
echo "${name:0:4}" # prod- Variable assignment uses
name=valuewith no spaces and no$on the left-hand side. - Double quotes allow variable and command substitution but block word splitting and globbing; single quotes block everything.
- Leaving expansions unquoted risks word splitting on IFS and unintended glob expansion — quote by default.
${var:-default},${var:=default}, and${var:?message}provide concise ways to handle missing or empty values.- Arithmetic must be done explicitly via
$((...)),((...)), orlet, since all Bash variables are stored as strings. - Tools like ShellCheck catch quoting and expansion mistakes statically, before a script ever runs.
Practice what you learned
1. What happens when you run `rm $file` where `file="my report.txt"` and the variable is left unquoted?
2. Inside single quotes ('...'), which of the following is expanded?
3. What does `${dir:-/tmp/output}` evaluate to if `dir` is unset?
4. Why is `${name}.log` sometimes necessary instead of `$name.log`?
5. Which statement about Bash variable typing is correct?
Was this page helpful?
You May Also Like
Writing Your First Bash Script
Get hands-on with the anatomy of a Bash script — shebang, permissions, execution, comments, and structuring commands into a reusable, repeatable tool.
Arrays in Bash
Learn how to create, index, and iterate indexed and associative arrays in Bash, and how to use them to write scripts that handle lists of data correctly.
Conditionals in Bash (if, case)
Master Bash's conditional constructs — if/elif/else, test expressions, [[ ]] versus [ ], and case statements — to make scripts branch correctly on real-world conditions.
Environment Variables and PATH
Understand how environment variables are set, exported, and inherited by child processes, and how PATH determines which executable a bare command name resolves to.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics