find and xargs exit codes: find's coarse 0/>0 versus xargs's 123-127 ladder

What it is

find's own manual is deliberately vague about anything beyond a boolean: "find exits with status 0 if all files are processed successfully, greater than 0 if errors occur. This is deliberately a very broad description." It adds a genuinely important caveat: on a non-zero exit, "you should not rely on the correctness of the results of find" — some starting points, or some pending -exec ... {} + invocations, may never have run at all.

xargs is far more specific about how the invoked command failed:

Code	Meaning
0	success (and any commands xargs ran also exited 0)
123	some invocation of the command exited with a status other than 0 or 255
124	the command exited with status 255 (xargs then stops reading further input)
125	the command was killed by a signal
126	the command cannot be run (found but not executable)
127	the command was not found
1	some other error occurred (in xargs itself)

The manual adds a mechanical detail that matters for scripting: commands run by xargs are launched directly with execvp(), not via a shell, so "the shell's (128 + signal) convention for reporting that a process had been killed by a signal is not used by xargs" — 125 is xargs's own code for that case, not 128+signal.

Why it matters

A common pattern, find . -name '*.log' | xargs rm, mixes find's coarse "something went wrong somewhere" with xargs's specific ladder. A permission error on one subdirectory makes find exit non-zero (but it still fed every file it could read to xargs), while a single unreadable target file passed to rm would surface through xargs's own 123 (ordinary non-zero exit), not through find's code at all — the two failures are reported completely independently and a pipeline that only checks the last command's $? sees only xargs's half of the story.

How to apply

• After find | xargs, check both exit codes if the shell/pipeline allows it (bash pipefail plus PIPESTATUS); a non-zero find alongside a zero xargs means some files were silently never listed.
• Treat find's non-zero as "results may be incomplete," not merely "an error was logged" — re-run with -print/-ls diagnostics or narrower starting points to find what was skipped.
• For xargs, branch on 126/127 as configuration problems (wrong binary name/path) versus 123/124/125 as problems with individual invocations of an otherwise-correct command.
• Use find ... -print0 | xargs -0 ... when file names may contain spaces or newlines, independent of the exit-code question.

Pitfalls

• Assuming find's exit code tells you which file or directory failed — it does not; you must inspect its stderr.
• Assuming xargs's 125 follows the shell's 128+signal numbering; the manual explicitly says it does not.