所以，给出三个选项…
find .... -delete find .... | xargs rm ... find .... -exec rm ...; ..或其变化，哪个选项是可取的？
我猜测没有硬性的答案，具体的情况会决定最好的select（请给它们命名！）
干杯。
选项1将避免产生外部过程，这在强调条件下是有用的。
选项2将产生一个单一的xargs进程，只会根据需要产生尽可能多的rm进程。 此选项通常与-print0和-0一起使用，以处理带空格和/或换行符的文件名。
选项3将为每个文件产生一个rm进程。
GNU find（或任何符合POSIX标准的find版本）允许使用第四个选项， find .... -exec rm -r {} + ，它将用尽可能多的文件名运行rm ，以便只产生有限的他们。
我更喜欢使用find ... > file.txt广泛查看文件，然后使用find ... -delete所以我知道完全相同的结果将被删除（通过参数大多是防弹的，主要是）。
GNU findutils文档的“清理”部分讨论了删除文件的主题。 你可以在你的系统上使用“info find”或者在Emacs中阅读。 您也可以在http://www.gnu.org/software/findutils/manual/html_node/find_html/Cleaning-Up.html#Cleaning-Up上在线查看 。
find .... -delete
这是最安全的（针对符号链接竞争）和高性能（因为在pipe道缓冲区已满时不需要执行任何操作或执行上下文切换）选项。 但是请记住，删除意味着深度。
find .... | xargs rm ...
在其他人有权访问正在清理的树的情况下，这是非常危险的。例如，假设find命令确定/var/tmp/scratch/me/.ssh/config与其要求匹配，并因此打印该名称标准输出。 xargs命令将读取它并将其添加到数据结构中。 不久之后（当xargs读取-s选项的缺省值指示的字节数时）xargs将fork和exec rm删除它。 但是，在此期间，其他人也可能这样做：
$ cd /var/tmp/scratch $ mv me me.old $ ln -s /root me
然后，当rm去删除/var/tmp/scratch/me/.ssh/config时，会发出系统调用unlink（“/ var / tmp / scratch / me / .ssh / config”）。 因为内核会为你parsing符号链接，这相当于调用了unlink（“/ root / .ssh / config”）。 如果xargs进程以root身份运行，那么/root/.ssh/config将被删除，尽pipe您没有在命令行中指定-L。 为此，如果安全性很重要，请使用-delete。 您可以在GNU find手册的“安全注意事项”部分阅读更多关于这方面的内容。
find .... -exec rm ...;
因为这也涉及fork / exec，所以它具有上面提到的相同的安全问题。
总之，不使用-delete的唯一原因是与缺less对-delete的支持的系统兼容。