In bash, why is `files=($(find . -name '*.log'))` an unsafe way to capture a list of filenames into an array, and what would you use instead?

## What goes wrong ```bash files=($(find . -name '*.log')) ``` Command substitution yields a single string containing the command's stdout with trailing newlines removed. Inside the array assignment the words are unquoted, so bash performs two more steps on that string: 1. **Word splitting** on `IFS`, whose default is space, tab and newline. Every one of those characters inside a filename becomes an element boundary. 2. **Pathname expansion** on each resulting word. A word containing `*`, `?` or `[...]` is replaced by matching filenames — or, if nothing matches, left as-is, which is a different kind of surprise. So `./app error.log` becomes the elements `./app` and `error.log`, neither of which exists. A file literally named `*` expands to every entry in the directory. The array's length no longer corresponds to the number of files, and later code that trusts `${#files[@]}` is now wrong. This is not a theoretical concern in production: filenames from uploads, exports, media libraries and Windows-originated shares routinely contain spaces, and newlines in filenames are legal on every POSIX filesystem. ## The line-oriented fix: mapfile ```bash mapfile -t lines < /var/log/app/index.txt ``` `mapfile` (also spelled `readarray`) reads lines from standard input into an array, one line per element, with no splitting and no globbing. `-t` removes the trailing newline from each line, which you almost always want. It arrived in bash 4.0, so it is unavailable on the bash 3.2 that Apple ships. To read from a command rather than a file, redirect from a process substitution: ```bash mapfile -t files < <(find . -name '*.log') ``` The redirection matters. `find ... | mapfile -t files` leaves the array empty in a default bash, because the right-hand side of a pipeline runs in a subshell whose variables die with it — the mechanics of that belong to subshell semantics, but the practical rule is: feed `mapfile` with `< <( ... )`, not with a pipe. ## The filename-safe fix: NUL delimiters A newline is a legal character in a filename, so line-oriented reading is still ambiguous for paths. The only byte that cannot appear in a filename is NUL, which is why `find` offers `-print0`: ```bash mapfile -d '' -t files < <(find . -name '*.log' -print0) # bash 4.4+ ``` `-d ''` sets the delimiter to NUL. It was added in bash 4.4. On anything older, or when you want maximum portability, use the read loop, which works back to bash 3.2: ```bash files=() while IFS= read -r -d '' f; do files+=("$f") done < <(find . -name '*.log' -print0) ``` Each appended value is quoted, so it stays a single element regardless of its contents. ## Checking what you got After filling an array, the cheap sanity check is to print boundaries rather than a joined string: ```bash printf '%d files\n' "${#files[@]}" printf '[%s]\n' "${files[@]}" ``` If a single file has become two elements, this shows it immediately, whereas `echo ${files[@]}` hides every boundary. One more detail: when a directory has no matches, `find` prints nothing, so `mapfile` produces an empty array and `${#files[@]}` is 0. That is a clean, testable outcome — better than the glob-based alternative, where an unmatched pattern is left literal unless `nullglob` is set. ## When globbing is the better tool If you only need files in known directories and no recursion, a plain glob is both simpler and inherently safe, because pathname expansion produces a proper word list without passing through text: ```bash files=(./logs/*.log) ``` Each match is one element, spaces and all, with no splitting involved. Reach for `find` plus `mapfile` when you need recursion, predicates such as `-mtime`, or a traversal you cannot express as a pattern. ## What an interviewer is listening for The weak answer is "quote it" — `files=("$(find ...)")` is worse, since it produces exactly one element containing the whole output. The strong answer names the two expansion steps that damage the data, distinguishes line-safe from filename-safe, and states the bash version each solution needs.