Quote `$(...)` to prevent word splitting

Problem

`$(cmd)` and the older ```cmd``` are subject to the same word splitting and globbing as bare variable expansions. When the command output contains spaces, newlines, or glob characters, the receiving command sees the wrong number of arguments. The classic trap is using `$(ls)` or `$(find ...)` to feed a loop or another command — any filename with a space breaks it.

Bad

# Each filename with a space becomes multiple args
for f in $(find . -name "*.log"); do
  echo $f
done

cp $(get_paths) /backup/

Good

# Use a while-read loop with NUL-delimited output
while IFS= read -r -d '' f; do
  echo "$f"
done < <(find . -name "*.log" -print0)

# Or, when you trust the output is a single value, quote it
cp -- "$(get_path)" /backup/

Explanation

Filenames in POSIX may contain any byte except NUL and `/`. The only universally safe separator is the NUL byte (`\0`), which is why `find -print0` paired with `read -d ''` is the canonical pattern for iterating over arbitrary filenames. For single-value command substitution, just quote it.

Related

SC2086

SC2207

SC2044

When It Matters

Unquoted command substitution is word-split and globbed, so any output containing spaces, tabs, newlines, or glob characters produces the wrong argument list. rm $(find . -name "*.tmp") fails on the first filename with a space; chown $(cat owner.txt) breaks if the file has a trailing space. Because command output is data you do not control, this is where quoting bugs turn into security bugs.

Second Example

Exceptions

Splitting is intentional when the command emits a list of whitespace-free tokens meant to become separate arguments, such as a flags string. Say so with a comment and, ideally, disable globbing with set -f around the line.

Faq