Quoting and Escaping

Before the shell runs a command it rewrites the line you typed: it expands variables, splits the result into words on whitespace, expands globs like *.conf against the filesystem, and runs anything in backticks or $( ). Quoting and escaping are how you switch parts of that machinery off. A single quote turns everything inside it into a literal string; a double quote keeps variable and command substitution but stops word splitting and globbing; a backslash escapes exactly the next character. Nothing else changes the meaning of these rules.

This is not a style preference — it is the boundary between a script that survives real input and one that breaks on the first filename with a space in it. The single most common shell bug in production is an unquoted $variable that held an empty value, a path with a space, or a leading dash, and silently turned one argument into zero, two, or a flag. Knowing precisely what each quoting form disables is what lets you reason about a command instead of pasting it and hoping.

Single Quotes, Double Quotes, and the Backslash

Single quotes are the strongest and the simplest: every byte between them is literal, including $, *, backslashes, and newlines. The one thing you cannot put inside single quotes is another single quote — there is no escape for it, because the quoting is absolute. Reach for single quotes whenever the text must arrive at the program byte-for-byte: an awk or sed program, a regular expression, a password, a JSON snippet.

Double quotes are the workhorse. Inside them the shell still performs parameter expansion ($VAR, ${VAR}), command substitution ($(cmd)), and arithmetic ($(( ))), but it does not split the result into words and does not expand globs. That combination is what you want almost all of the time: you need the value of a variable, and you need it to stay one argument no matter what characters it contains. The backslash escapes a single following character, removing whatever special meaning it had — \$ is a literal dollar sign, \ is a literal space, and a backslash at the very end of a line continues the command onto the next.

$ file='my report.txt'
$ rm $file        # word-split: tries to remove 'my' and 'report.txt'
$ rm "$file"      # one argument: removes 'my report.txt'
$ echo '$file'    # literal: prints $file
$ echo "$file"    # expands: prints my report.txt
$ echo \$file     # escaped: prints $file

What Each Form Disables

The useful way to hold this in your head is as a table of which shell stages each quoting form switches off. Word splitting and globbing are the two stages that surprise people, because they happen after a variable is expanded — the shell expands $file to my report.txt and only then chops it on the space. Both single and double quotes stop those two stages; the difference between them is purely whether expansion still runs.

Form	Variable / command expansion	Word splitting	Glob expansion
Unquoted	Yes	Yes	Yes
"double"	Yes	No	No
'single'	No	No	No
\c (backslash)	Disables for one char	n/a	n/a

One consequence is worth stating plainly: "$@" and "$*" are not interchangeable. "$@" expands to each positional parameter as a separate, individually quoted word — the only correct way to forward a script's arguments to another command. "$*" joins them into a single word separated by the first character of IFS (a space by default). Forwarding arguments with $@ unquoted, or with "$*", is how wrapper scripts mangle paths that contain spaces.

Heredocs and Embedded Programs

When you need to feed several lines into a command — a config block, a SQL statement, a remote script over ssh — a here-document is cleaner than chained echo calls. The quoting of the delimiter word controls expansion of the whole body, mirroring the single-versus-double rule. An unquoted delimiter (<<EOF) expands variables and command substitutions inside the body; a quoted delimiter (<<'EOF') passes the body through verbatim.

# Expanded: $USER and $(hostname) are substituted now, locally
$ cat <<EOF
running as $USER on $(hostname)
EOF

# Literal: the remote shell sees $USER and runs it there
$ ssh web01 bash <<'EOF'
echo logged in as $USER
EOF

Using <<-EOF (with the dash) strips leading tab characters from each body line and from the closing delimiter, so you can indent a heredoc inside a function or loop with tabs without those tabs ending up in the output. Spaces are not stripped — only tabs — which is a frequent source of "why won't my closing EOF match" errors when an editor has expanded tabs to spaces.

Quoting Across the Layers

A command rarely lives in just one shell. The classic trap is a value that passes through two shells — a local shell and a remote one over ssh, or the outer shell and an inner one in bash -c "...". Each layer strips one level of quoting, so a string that needs to survive both must be quoted twice. ssh web01 "rm '$file'" expands $file locally, then hands the remote shell a line that still has single quotes protecting any spaces; getting either layer wrong deletes the wrong thing or nothing.

When the quoting gets deep enough to be unreadable, stop hand-escaping and let the shell build the safe form for you. The printf %q builtin emits a string quoted so that feeding it back to the shell reproduces the original exactly, and ${var@Q} in Bash 4.4 and later does the same for a variable. For passing arguments to a remote host, the reliable pattern is to avoid a second shell parse entirely where you can, and where you cannot, generate the escaped form with printf %q rather than guessing at how many backslashes you need.

$ path="/var/log/my app/app.log"
$ printf '%q\n' "$path"
/var/log/my\ app/app.log
$ ssh web01 "tail -n 50 $(printf '%q' "$path")"