Variables and Quoting in Bash

Analogy categoryAnalogies

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.

bash

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 greeting

Double 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.

bash

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.txt

Unquoted 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.

bash

# 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=value with 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 $((...)), ((...)), or let, 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?

Writing Your First Bash Script

Conditionals in Bash (if, case)

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

Topics covered

#Bash#LinuxShellScriptingStudyNotes#DevOps#VariablesAndQuotingInBash#Variables#Quoting#Assignment#Expansion#StudyNotes#SkillVeris

Variables and Quoting in Bash