奇怪的行为 grep -rnw答案

【问题标题】：Strange behavior grep -rnw奇怪的行为 grep -rnw
【发布时间】：2018-07-27 12:19:08
【问题描述】：

我在 MacOS 中使用 grep (BSD grep) 2.5.1-FreeBSD，我发现了以下行为。

我有两个 *.tex 文件。每一个都包含以下几行

$k$-th bit of
$(i-m)$-th bit of

分别。我跑的时候

grep --color -rnw . -e '\$-th bit of' --include="*.tex"

我只得到了第二个文件，即 $(i-m)$-th 位，而我希望有两行。你能帮我理解这种行为吗？

【问题讨论】：

您应该考虑通过接受或赞成答案来为您的问题提供反馈。从你questions 的历史来看，我认为它从未发生过。请记住，接受或投赞成票是本网站表示“谢谢”的方式

标签： grep

【解决方案1】：

切勿使用 -r 或 --include 或任何其他 grep 选项来查找文件。当有一个名为find 的非常好的工具用于查找文件时，GNU 家伙真的把这些选项添加到 grep 中搞砸了，现在他们已经把 grep 变成了一个复杂的查找文件和全局匹配的糊状物文件中的正则表达式并打印结果 (G/RE/P)。

保持简单 - 找到带有find然后g/re/p的文件，然后使用grep：

find . -name '*.tex' -exec grep --color -n '\$-th bit of' {} +

正如其他人指出你的 g/re/p 问题是 -w arg 所以我已经删除了上面的那个。

【讨论】：

我有兴趣更深入地讨论差异。认为find ... -exec 会为找到的每个文件创建分支，而grep -r 只是其中一个，这是否正确？我知道find 有一些重要的优化，所以也许它权衡了分叉的成本..
Josh - 我不知道 grep -r 的行为如何，但我的答案中的 find 命令在文件上批量调用 grep（这就是最后的 + 所做的）而不是单个文件（如果您希望它一次 grep 1 个文件，请将 + 更改为 \;）。我不是什么时候分叉工具的专家，但我希望find -exec grep 和grep -r 之间的性能差异可以忽略不计。
感谢您的回复，我不知道！不过，这是有道理的，并且可能会在广泛的搜索领域中提高性能。也许有一天我无聊的时候会偷看grep的源代码。我主要对性能感到好奇，因为在处理遗留系统时，我发现不同实现的差异长达一分钟。
听起来不错，如果他们打算在grep 中实现sort 或curl 或任何其他工具功能，请告诉我，因为他们显然认为包含finds 功能是好主意，所以谁知道他们还有什么袖手旁观:-)！
我想说grep -r 是软件开发人员最常用的命令之一。虽然 find 是一个更适合查找文件的工具，但使用 find . -exec grep 需要更多的输入。

【解决方案2】：

我有相同版本的 grep。

这是由您使用-w 选项引起的：

 -w, --word-regexp
         The expression is searched for as a word (as if surrounded by `[[:<:]]' and `[[:>:]]'; see re_format(7)).

字符串$k$-th bit of 的匹配部分在左侧以单词字符为界（即k），因此匹配被视为在“单词”内，因此不能满足“作为一个整体搜索”的要求。

尝试不使用-w，它会正常工作。

【讨论】：