If you are dealing only with a few pathnames that do not contain whitespace, then they are equivalent.
On some systems, the maximum length of a single command-line (actually, environment plus arguments sent to an exec(2)-family call) is limited (see kern.argmax). On a limited system, if find
produces too much output, the shell would not be able to fit it all into the surrounding command line. To fix this, xargs
takes the output of find
and combines the ‘words’ (yes, words, not lines, see below) into groups that fit into a single command-line.
Second, both xargs
and the shell (via backticks) will split up find
's output into arguments for rm
by tokenizing the output at every run of any combination of space, tab, or newline characters (this is a simplification since they both have their own quoting rules that are close, but not identical). If find
-print
s a pathname of “.//foo/bar quux”, rm
will eventually see two arguments (“.//foo/bar” and “quux”). If a file named quux
existed in the cwd from which you started, it would be gone when it was all over (and “.//foo/bar quux” would still be there!).
So the most robust method is to use find
's -print0
and xargs
's -0
POSIX-extension. Working together, they can be used to robustly transport any legal pathname from the output of find
to the command-line of any other command on any system that supports the two extensions.
find . -name foo\* | xargs -0 rm
The robustness comes from the fact that the NUL byte that both extensions use to terminate pathnames is the only disallowed byte in just about all (Unix-oid) OSes.
xargs
runs onerm
with the piped-in input as arguments. John T's answer shows how to run onerm
for each file found.