Bash on Linux: Quote Filenames with Spaces Correctly

A script that works with report.txt but fails with “monthly report.txt” does not prove Linux cannot handle spaces. The shell may have turned one value into several arguments before the program received it. Correct quoting prevents this class of mistake at the input boundary.

1. Start with an output-only example

These examples target Bash with its default IFS. Use a disposable Bash session, not PowerShell or an arbitrary shell. No files with these names need to exist.

report_name='monthly sales report.txt'
printf '[%s]\n' $report_name
printf '[%s]\n' "$report_name"

The expected first output has three lines: [monthly], [sales], [report.txt]. The second has one line: [monthly sales report.txt]. Quoting an assignment does not automatically protect subsequent uses.

2. Single and double quotes have different purposes

The Bash quoting documentation describes mechanisms for preserving characters. Single quotes keep literal text; double quotes still allow variable expansion. For a filename variable, the usual intention is to expand its value while keeping it as one argument.

printf '%s\n' '$report_name'
printf '%s\n' "$report_name"

The first prints the variable name including $, while the second prints its value. Single-quoting the expression is not a substitute for safely expanding it.

3. Spaces are not the only concern

The word-splitting rules explain how unquoted expansion results can split into words. In ordinary argument contexts, filename patterns such as * can also expand to matching names. Testing only simple filenames is insufficient.

Passing "$report_name" keeps a path value as one argument. It does not verify existence, grant access or prove the path is within an allowed directory. Those remain separate script responsibilities.

4. Use arrays for multiple paths

reports=('monthly sales report.txt' 'meeting notes.txt')
printf '[%s]\n' "${reports[@]}"

Expect two lines, one per element. Avoid packing independent paths into a string and relying on splitting to reconstruct them. This array syntax is Bash-specific; invoking the script with sh is not equivalent.

5. Checklist before real operations

• Test spaces, Unicode and literal asterisks.
• Define whether empty values are errors or acceptable inputs.
• Where supported, use -- to end options before paths that may start with a dash.
• Do not use eval to repair quoting; do not turn data into executable code.
• Move from printf demonstrations to writes or deletions only after confirming each argument and the intended scope.

Keep one value as one argument through double-quoted expansion, and store multiple values as separate elements. Explicit argument handling makes scripts easier to read and test.