☰

在 /proc 和原始磁盘上使用“grep”不是一个好主意的具体原因是什么？

tag-icon • tag-icon linux filesystems grep
在 /proc 和原始磁盘上使用“grep”不是一个好主意的具体原因是什么？

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

我收集了/proc类似的磁盘，/dev/sda1它们是导致 grep 失败的罪魁祸首。

我很想了解一些关于“为什么”的深层技术背景。我认为其中的一些链接/proc在遍历时会产生无限循环，我读到还有更多原因，但没有具体原因。

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

答案1

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

  1. 是的，您可以运行 grep 来查看 的二进制内容/dev/sda1。但是，对于现代的大硬盘来说，这将花费很长时间，而且结果可能没什么用。

  2. 是的，您可以 grep 内容，/proc但请注意，您的计算机内存以文件形式映射到那里。在具有 GB RAM 的现代计算机上，这将花费很长时间进行 grep，而且结果可能没有用。

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

其他有问题的文件/dev

如果有足够的耐心，可以 grep下面的硬盘和硬盘分区/dev。其他文件（提示：用户2313067)，但可能会引起问题：

  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

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

    $ 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 搜索某些文件或目录。例如，你可以使用以下命令从 grep 的递归搜索中排除所有名为proc、sys和 的目录：dev

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

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

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

相关内容