Quoting Pitfalls and Why to Always Quote Variables

Word Splitting on Unquoted Variables

When a variable containing spaces is used unquoted, bash splits it into multiple separate words on IFS before passing them to a command, which usually is not what was intended.

Example: Word Splitting on Unquoted Variables

#!/bin/bash
count_args() { echo "received $# argument(s)"; }

phrase="hello there world"
count_args $phrase
count_args "$phrase"

Accidental Globbing

An unquoted variable whose value contains glob characters like * gets expanded against real filenames in the current directory, which can silently turn one literal string into a list of unrelated filenames.

Example: Accidental Globbing

#!/bin/bash
touch star_demo_a.txt star_demo_b.txt
pattern="star_demo_*.txt"
echo "unquoted (expands against real files): $pattern"
echo unquoted: $pattern
echo "quoted (kept literal): \"$pattern\""
rm -f star_demo_a.txt star_demo_b.txt

Disappearing Empty Variables

An unquoted empty (or unset) variable expands to nothing at all, effectively vanishing from the command line, which can shift what the next real argument is interpreted as. Quoting keeps it as a genuine empty-string argument.

Example: Disappearing Empty Variables

#!/bin/bash
show_args() {
    echo "count: $#"
    for a in "$@"; do echo "[${a}]"; done
}

empty_var=""
show_args $empty_var second
echo "---"
show_args "$empty_var" second

A Safe Default Habit

Quoting every variable expansion by default, and only deliberately leaving one unquoted when word splitting or globbing is actually wanted, avoids an entire category of subtle bugs.

Note: Tools like shellcheck flag most unquoted-variable mistakes automatically and are worth running on any real script.

Example: A Safe Default Habit

#!/bin/bash
filename="my report.txt"
touch "$filename"
if [[ -f "$filename" ]]; then
    echo "file with a space in its name handled correctly"
fi
rm -f "$filename"