Paths with spaces and special characters across bash, zsh, PowerShell and cmd

What it is

A file name containing a space, a glob character (*, ?, [), a leading dash, or a shell metacharacter (&, ;, backtick) is ordinary and legal on every filesystem this series covers, but each scripting environment has its own way of mishandling it.

Why it matters

• bash and zsh: in bash an unquoted $var or command substitution is subject to word splitting and filename expansion; the GNU Bash manual's Quoting section defines quoting as the mechanism that removes that special meaning. rm $file silently becomes several arguments if $file contains a space; "$file" does not. zsh by default does not split unquoted $var, but still splits unquoted $(...) and drops empty unquoted values, so quote there too. Bash arrays ("${arr[@]}") are the correct way to build an argument list without falling back to a single string.
• PowerShell: -Path parameters accept wildcards, so a literal file name containing [ or ] can be misread as a pattern. Get-ChildItem documents -LiteralPath as a parameter whose value "is used exactly as it's typed" and where "no characters are interpreted as wildcards" — use it whenever the path came from data rather than from a pattern the caller intended. about_Quoting_Rules documents when single versus double quotes matter for variable expansion inside the path string itself.
• cmd.exe: arguments containing spaces must be wrapped in double quotes, and a path beginning with / or - can be misread as a switch by some tools; unquoted, concatenated paths in batch code reproduce the unquoted-variable bug.
• find and xargs: file names can legally contain newlines, which breaks the default line-based handoff between the two tools. find(1) documents -print0 as printing the full path followed by a null character instead of a newline; xargs(1) documents its null-delimited input mode (-0/--null) as reading a null character instead of any whitespace as the separator between items. The pairing find ... -print0 | xargs -0 ..., like find ... -exec cmd {} +, survives every legal file name, including ones with embedded newlines.

How to apply

• Quote every shell variable expansion and command substitution in bash/zsh ("$var", "$(cmd)"), prefer arrays over string concatenation, and put -- before file operands (rm -- "$f") or prefix ./ so a leading dash is not read as an option.
• Use -LiteralPath in PowerShell cmdlets whenever the path value came from a variable, a file listing, or user/agent input rather than from a pattern you wrote yourself.
• Quote every path assembled in a batch file, and prefer PowerShell for scripts that must handle unpredictable file names on Windows.
• Default to find ... -print0 | xargs -0 (or find ... -exec cmd {} +) over any newline-based find | xargs pipeline when the file set is not fully controlled.

Pitfalls

• Testing only with space-free file names and meeting the quoting bug on real data later.
• Using -LiteralPath in one cmdlet of a pipeline and -Path in the next, so wildcard interpretation reappears downstream.
• Assuming -print0/-0 exist everywhere; GNU, the BSDs and macOS have long had them, but they entered POSIX only in the 2024 edition, so for older or minimal systems use -exec ... {} +.