/proc 和原始磁盘上的 `grep` 是一个坏主意的确切原因是什么？

Question

我grep -r "searchphrase" /今天跑了，但没有用。我做了一些研究，发现find / -xdev -type f -print0 | xargs -0 grep -H "searchphrase"这是正确的方法。

我收集/proc和磁盘/dev/sda1是不成功的 grep 的罪魁祸首。

我会喜欢一些关于“为什么”的深厚技术背景。我认为内部的某些链接在/proc遍历时会产生无限循环，我读到有更多原因，但没有具体说明。

另外，当原始磁盘被 grep 时会发生什么？是否可以不解释二进制数据（/dev/sda1据我所知可以在 上访问？），因为只有mount具有文件系统类型的 a才能使磁盘中的数据易于理解？因此，仍然可以对二进制字符串进行 grep 吗？

Answer 1

是的，你可以grep /dev/sda1，/proc但你可能不想。更详细地：

1. 是的，您可以运行 grep 的二进制内容/dev/sda1。但是，对于现代大硬盘，这将需要很长时间，而且结果可能没有用。

2. 是的，您可以 grep 的内容，/proc但请注意，您的计算机内存被映射为文件。在具有千兆字节 RAM 的现代计算机上，这将需要很长时间来 grep，同样，结果不太可能有用。

作为一个例外，如果您要在文件系统损坏的硬盘上查找数据，您可能会grep something /dev/sda1作为尝试恢复文件数据的一部分运行。

其他有问题的文件 /dev

下面的硬盘和硬盘分区/dev可以，如果有足够的耐心，grepped。但是，其他文件（提示：user2313067）可能会导致问题：

1. /dev/zero是一个无限长的文件。幸运的是，grep（至少 GNU 版本）足够聪明，可以跳过它：

   $ grep something /dev/zero
   grep: input is too large to count
   

2. /dev/random并且/dev/urandom也是无限的。grep something /dev/random除非grep发出停止信号，否则该命令将永远运行。

   /dev/urandom在生成密码时使用 grep 很有用。例如，要获取五个随机字母数字字符：

   $ grep --text -o '[[:alnum:]]' /dev/urandom | head -c 10
   G
   4
   n
   X
   2
   

   这不是无限的，因为在它接收到足够的字符后，head关闭管道导致 grep 终止。

无限循环

“......链接......遍历时创建无限循环......”

Grep（至少是 GNU 版本）足够聪明，不会这样做。让我们考虑两种情况：

1. 使用该-r选项，除非在命令行中明确指定，否则grep不会跟随符号链接。因此，无限循环是不可能的。

2. 使用该-R选项，grep确实遵循符号链接，但它会检查它们并拒绝陷入循环。为了显示：

   $ mkdir a
   $ ln -s ../ a/b
   $ grep -R something .
   grep: warning: ./a/b: recursive directory loop
   

排除有问题的目录 grep -r

顺便说grep一句，提供了一个有限的工具来阻止 grep 搜索某些文件或目录。例如，您可以排除所有目录命名proc，sys以及dev可以从grep的递归搜索具有：

grep --exclude-dir proc --exclude-dir sys --exclude-dir dev -r something /

或者，我们可以排除proc、sys和dev使用 bash 的扩展 globs：

shopt -s extglob
grep -r something /!(proc|sys|dev)