Word Splitting and IFS

## The two extra steps on an unquoted expansion When bash substitutes a parameter (`$var`, `${var}`), the text it produces is **not automatically one word**. Unless the expansion appeared inside double quotes, bash applies two further steps to the result: 1. **Word splitting** — the result is chopped into words at the characters listed in the shell variable `IFS`. 2. **Pathname expansion (globbing)** — each word produced by step 1 is then treated as a glob pattern and, if it matches files, replaced by the matching names. Only after both steps does bash know how many arguments the command gets. Everything below follows from that ordering. ## What IFS is `IFS` stands for *Internal Field Separator*: the shell variable holding the delimiter characters used for splitting. Its default value is space, tab and newline, which you can write literally as `IFS=$' \t\n'`. Splitting obeys two different rules depending on the character: - **Whitespace delimiters** (space, tab, newline) collapse: a run of them is one delimiter, and leading or trailing runs are ignored. `" a b "` splits into exactly two words. - **Non-whitespace delimiters** (a comma, a colon) delimit one field each, so repeats produce *empty* fields. With the default `IFS`, splitting therefore never produces empty words — which is why an empty variable expands to nothing at all rather than to one empty argument. ## The example, step by step ```bash files="report 2024.txt" printf '[%s]\n' $files # [report] then [2024.txt] -> two words printf '[%s]\n' "$files" # [report 2024.txt] -> one word ``` Bash expands `$files` to the eight-plus characters `report 2024.txt`, splits at the space into `report` and `2024.txt`, globs each (neither contains a glob character, so both survive unchanged), and hands `rm` two arguments. The single quotes around the assignment mattered only while bash was parsing the assignment line: they stopped the space from splitting *that* line. They are not stored in the variable and cannot protect a later expansion. ## Globbing runs after splitting, on the pieces The second step surprises people because it means a value can grow: ```bash v="* one.txt" printf '[%s]\n' $v # every file in the directory, then [one.txt] ``` Splitting produces the words `*` and `one.txt`; the `*` is then a glob and expands to the directory listing. A value read from a file, a filename, or a CLI argument can therefore inject both extra arguments and a directory listing into your command line. This is the mechanism behind the classic `for f in $(ls)` bug: any name containing a space becomes two loop iterations, and a name containing `*` or `?` gets glob-expanded again. ## What quoting does Double quotes suppress both steps: the expansion becomes exactly one word, whatever whitespace or glob characters it contains. That is the whole reason the house rule "quote every expansion unless you have a specific reason not to" exists. `"$files"`, `"$1"`, `"$(command)"`, `"${arr[@]}"` — quoting is applied where the value is *used*. A few practical consequences: - `rm -- "$files"` also needs the `--`, because a filename that begins with `-` would otherwise be read as an option; quoting fixes splitting, not option parsing. - If a variable really holds a list, use an array so each element keeps its own identity; a space-joined string is lossy for names containing spaces. - Deliberate splitting is legitimate but rare: `cmd $flags` where `flags="-v --color=never"` works precisely *because* the value is split. Reviewers cannot tell intentional splitting from a bug, so annotate it or, better, use an array. ## Getting it caught for you ShellCheck's SC2086 ("Double quote to prevent globbing and word splitting") fires on every unquoted expansion in an argument position, and it is the single highest-value warning in shell linting. In an interview, being able to narrate *split, then glob, then run* — in that order, with `IFS` named as the thing that decides where the splits happen — is the answer being probed for.