In zsh, `files="a.txt b.txt"; touch $files` creates one file literally named `a.txt b.txt`, while bash creates two files. Why do the shells differ, and what are the correct ways to get the two-file behaviour in zsh?

## What word splitting is In a POSIX shell, expansion happens in stages. After a parameter like `$files` is replaced by its value, the result is broken into separate words at every run of characters found in `IFS` (by default space, tab, newline). That second stage is *field splitting*, or word splitting. It is why `files="a.txt b.txt"; touch $files` creates two files in bash: the shell hands `touch` two arguments, not one. It is also the single largest source of bugs in shell code. A path containing a space, a filename from `find`, a variable holding a person's name — every one of them silently becomes several arguments unless the author remembered to write `"$files"`. This is why every shell style guide tells you to quote every expansion. ## What zsh does instead zsh's designers took the opposite default. An unquoted parameter expansion produces exactly **one** word regardless of the whitespace inside it, so `$files` and `"$files"` behave the same for a scalar. Your `touch` therefore creates one file whose name contains a space. The practical effect is that the quoting bug class largely disappears in interactive zsh. The cost is portability confusion: code copied from bash, or written by someone with bash reflexes, quietly changes meaning. ## The three ways to get splitting back ```zsh files="a.txt b.txt" touch ${=files} # split this one expansion on IFS setopt SH_WORD_SPLIT # shell-wide bash behaviour touch $files # now creates two files unsetopt SH_WORD_SPLIT emulate -L sh # sh emulation turns SH_WORD_SPLIT on among others ``` `${=name}` is zsh's per-expansion splitting flag; its mirror image is `${~name}`, which turns on *globbing* of the expansion's result (zsh does not glob expansion results by default either — bash does not glob them either, but bash's `GLOBSUBST`-like behaviour differs in detail, so treat `${~name}` as the deliberate opt-in). `setopt SH_WORD_SPLIT` is what `emulate sh` sets for you. ## The answer an interviewer wants: use an array All three switches are workarounds for using the wrong data type. A string holding several values is a list pretending to be a scalar. zsh has had arrays since long before bash did: ```zsh files=(a.txt "b c.txt") touch $files # two arguments, and the space in the second is preserved print ${#files} # 2 ``` An unquoted array in zsh expands to one word per element, and — crucially — elements containing spaces stay intact. That is the property no amount of `IFS` fiddling gives you in bash. The portable spelling that means the same thing in both shells is `"${files[@]}"`. ## The asymmetry that catches people zsh's no-splitting rule applies to **parameter expansion**. Unquoted **command substitution** is still field-split on IFS: ```zsh out=$(printf 'a\nb\n') print -l $out # one word: a and b on separate lines but a single argument print -l $(printf 'a\nb\n') # two words ``` So `for f in $(ls)` behaves in zsh much as it does in bash — badly, for filenames with spaces — while `list=$(ls); for f in $list` does not. If you are debugging why one loop splits and a seemingly identical one does not, this asymmetry is usually the reason. `IFS` itself still exists in zsh and still governs both this splitting and the `read` builtin. ## Why this shows up in interviews It is the cleanest example of a shell changing a default for safety and breaking compatibility as a result. A candidate who can say "zsh removed implicit word splitting because unquoted expansions are the classic shell bug, and the migration cost is that code assuming splitting silently changes behaviour" has understood the whole leaf. A candidate who says "zsh is broken" has not. A final practical note for migrating shared code: rather than sprinkling `${=var}` through a ported file, decide whether each variable is a scalar or a list. If it is a list, make it an array. If the file must be sourced by both bash and zsh, keep it to `"${arr[@]}"` and explicit quoting, which mean the same thing everywhere.