1

引用 find 的手册页（GNU findutils 4.7.0，强调我的）：

GNU find根据优先规则（参见PERATORS 部分），通过从左到右评估给定表达式来搜索以每个给定起点为根的目录树，直到结果已知（左侧为假）和操作, true for or )，此时 find 移动到下一个文件名。

因此，在find评估时，<expr1> -and <expr2>我希望<expr2>除非<expr1>为真，否则不会评估，我依靠它来避免一些错误消息，特别是，我不想find测试不可读的目录是否为空。这是一个SCCCE：

mkdir some_dir
chmod 333 some_dir
find * -readable ! -empty -printf "yes" -or -printf "no" -prune

产生

find: ‘some_dir’: Permission denied
no

添加（否则为隐式）-and和括号，评估的表达式find 应等效于

( ( -readable -and (! -empty ) ) -and -printf "yes" ) -or ( -printf "no" -and -prune )

因此，在意识到some_directory不可读之后，find应该放弃空性测试和评估-printf "yes"。相反，它应该跳转到-printf "no"和 finally的评估-prune。输出中的“Permission denied”表明它正在评估-empty。（从原始表达式中删除! -empty会使错误消失。）

使用-D tree检查评估树，我看到优化的形式（为了简洁和清晰而在此处编辑）是：

(  (  ( ! -empty ) -and -readable ) -and -printf "yes" ) -or ( -printf "no" -and -prune )

根据哪个-empty确实进行了评估，更糟糕的是，在此之前-readable完全搞砸了预期的逻辑。我认为这是一个错误。我对吗？

更新：（2020 年 5 月 26 日）已提交错误报告，并已被开发人员确认为错误。

4

1 回答 1

1

在我看来，这是 findutils 的“arm-swapping”优化中的一个错误，因为它没有考虑到这一点，-empty并且可能具有导致报告错误并以非零状态退出-xtype的副作用。find我已经报告了同样的问题-xtype，findutils 开发人员同意这是一个错误。解决这个 bug 也很困难，因为 findutils 没有办法关闭这个优化。 -O0等同于-O1已经应用它的那个。

如果你需要一个解决方法，我写了一个替代的find叫做bfs：https://github.com/tavianator/bfs。它与所有 GNU find 的选项完全兼容，并且没有这个错误。

于 2020-05-22T14:31:10.503 回答