![为什么'grep -L x](https://linux22.com/image/190339/%E4%B8%BA%E4%BB%80%E4%B9%88'grep%20-L%20x%20.png)
我有 GNU grep 3.3-1 (Debian Buster 中的当前版本)。
从man grep
:
退出状态
通常,如果选择了一行,则退出状态为 0;如果没有选择行,则退出状态为 1;如果发生错误,则退出状态为 2。但是,如果使用
-q
或--quiet
或--silent
并选择了一行,则即使发生错误,退出状态也为 0。
这与POSIX。 (-L
此处未指定。)
最新版本的完整文档和最新提交中的文档没有关于-L
( --files-without-match
)的更多详细信息。
grep -L x <<<x
(in bash
) 以代码 1 退出。我不确定这是否与文档一致(这里选择的行到底是什么?),但至少这是可以解释的:没有输入文件与必须没有x
.
grep -Lq x <<<x
并且grep -L x <<<x >/dev/null
都以代码 0 退出。好的,-q
这样更容易理解一点,但是为什么 stdout 重定向会影响退出代码呢?因此,为了在抑制输出的同时获得原始的退出代码行为,(set -o pipefail; /bin/grep -L x <<<x | cat >/dev/null)
需要进行类似的黑客攻击。这是为什么?
由于 GNU grep 被如此广泛地使用,我不确定这是一个错误grep
:我更有可能错过了一些东西。或者也许退出代码-L
只是不值得依赖的东西?即使您可以使用像这样的测试运行和源代码来了解当前版本的行为,但这种行为将来可能会发生变化,因为它与当前文档不一致。你怎么认为?
(顺便一提,在最新的提交中进行测试-L
除了非 2 退出代码(在in-eq-out-infloop
)和边缘情况(如-f /dev/null
(在skip-read
)中)之外,似乎没有进行其他测试。)
答案1
这是一个错误,这是GNU grep
3.4中已修复:
当标准输出为 /dev/null 时,“grep -L”的退出状态不再不正确。
[grep 3.2 中引入的 Bug#37716]