A cleanup script iterates with `for f in $(ls /var/uploads)` and then runs `rm $f`, over a directory where users choose the uploaded filenames. Which filenames break or subvert that loop, and how would you write it correctly?

## What the broken loop actually evaluates `for f in $(ls /var/uploads)` runs through three separate mechanisms, and each one is a chance for a filename to stop behaving like a filename. 1. **Command substitution** captures ls's standard output as one string and strips trailing newlines. 2. **Word splitting** then cuts that string at every character in IFS — by default space, tab and newline. Nothing about a filename tells bash where one ends; only IFS does. 3. **Pathname expansion** runs on each resulting word, so any word containing `*`, `?` or `[...]` is replaced by whatever matches in the *current* directory. Then the body repeats steps 2 and 3, because `rm $f` is unquoted too. ## The four filename shapes that break it **A space or tab.** `annual report.pdf` becomes two words. The loop runs `rm annual` and `rm report.pdf`, both of which fail — or, worse, succeed on unrelated files that happen to have those names. **A newline.** Filenames may contain any byte except NUL and `/`, newline included. One file becomes two iterations, and no amount of reading the list line by line can tell the two cases apart. This is the case that makes newline-delimited filename lists fundamentally ambiguous. **A glob character.** A user uploads a file literally named `*`. After splitting, that word undergoes pathname expansion and becomes *every* name in the current directory. A cleanup script can be made to delete files it was never pointed at. **A leading dash.** A file named `-rf`, `-f` or `--help` is passed to rm in option position. `rm` has no way to know it came from a variable; it reads it as flags. This is how a delete-one-file loop turns into a recursive force delete. ## Why parsing ls is the wrong starting point `ls` is a display tool. Its output layout depends on whether stdout is a terminal, on flags, and on the implementation; GNU coreutils will even quote or replace unprintable characters in some modes. There is no escaping convention you can reliably reverse. The shell already has a filename-listing primitive that returns *words, not text*: the glob. ## The correct idioms **Iterate a glob.** ```bash shopt -s nullglob # empty directory: zero iterations, not one literal '*' for f in /var/uploads/*; do [[ -f $f ]] || continue rm -- "$f" done ``` A glob expands to a list of *separate words* directly — no splitting stage runs over it, so spaces and newlines inside a name are harmless. Each word is a full path beginning with `/var/uploads/`, so no name can start with a dash. Without `nullglob`, an unmatched pattern stays literal and the loop runs once with the pattern itself, which is why the `-f` guard (or `nullglob`) is not optional. For a glob in the current directory, write `./*` for the same leading-dash protection. **Quote every expansion, and end option parsing.** `rm -- "$f"` is two defences: the quotes stop re-splitting and re-globbing, and `--` tells rm that everything after it is an operand. Most GNU and BSD tools honour `--`; `./` prefixes cover the ones that do not. **When you need a whole tree, use a NUL-delimited stream.** ```bash while IFS= read -r -d '' f; do rm -- "$f" done < <(find /var/uploads -type f -name '*.tmp' -print0) ``` `-print0` emits NUL-terminated names, `read -d ''` reads up to a NUL, `IFS=` stops leading and trailing whitespace being trimmed, and `-r` stops backslashes being interpreted. Feeding it with process substitution rather than a pipe also keeps the loop in the current shell, which matters if the body sets variables — the reason a piped loop behaves differently is a subshell topic of its own. ## The invariant to state in the interview A filename is a byte string, not a line of text. Any design that moves filenames through a whitespace- or newline-delimited channel is lossy for inputs an attacker chooses. Prefer channels that never lose the boundary: a glob, `find -exec`, or a NUL-delimited stream. And in a directory that untrusted users write to, assume every hostile name — leading dash, embedded newline, embedded glob — is present, because producing one costs nothing.