我正在搜索文件系统并使用grep。我看到一切正常，直到出现此错误：
Grep: /proc/sysrq-trigger: Input/output error
我已经在网上的各个地方找到了信息，其他地方遇到了同样的问题，但没有任何地方有效。我尝试了2＆gt; / dev / null来压制错误，但没有“跳过文件”，这实际上是我希望它会做的。相反，它只是停止进程（这是一个利用grep的find / sed进程）。我认为有一种方法可以使用grep指定要排除的文件，但我希望可能有更强大和更优雅的解决方案。
答案 0 :(得分：16)
听起来好像是递归搜索整个文件系统层次结构。这在大多数系统上都无法正常工作。
在Linux上，至少/proc和/sys是虚拟文件系统 - 它们与磁盘上的实际文件不对应。 /dev中的特殊文件也不是实际文件 - 它们对应于系统中的某些设备，例如硬盘，输入设备e.t.c.修改 - 有时甚至是读取 - 任何这些目录下的文件都不应该以不受控制的方式发生，因为你可能会崩溃内核，破坏你的文件系统甚至对硬件造成永久性损坏。
由于您使用find执行搜索，因此您需要限制其搜索范围：
使用明确的否定-path选项：
find / -maxdepth 2 -type f ! -path '/proc/*' ! -path '/sys/*'
使用-prune选项：
find / -maxdepth 2 -path '/proc' -prune -o -path '/sys' -prune -o -type f -print
使用-xdev选项可以完全避免降级到其他文件系统：
find / -maxdepth 2 -xdev -type f
您可以根据需要使用尽可能多的-path和/或-prune选项来微调find的输出。但是，我建议您在将输出传递给管道中的任何后续阶段之前检查其输出。
修改
以下是以不受控制的方式访问某些文件时造成的损坏的一些示例 - 通常为root：
如果/proc/kcore被视为root，则较旧的内核used to crash。我相信这不再发生了，但我遇到过这个问题，因为/proc/kcore是在2.4.x内核系列中引入的occasionally pops up again，所以我没有心情去实际测试它... < / p>
通过/dev/中的设备节点读取块设备会严重降低该设备上的任何其他操作的速度，因为它会绕过VFS和各种缓存。想象一下，例如，直接读取6TB RAID-5分区，而其他进程尝试通过已安装的文件系统正确使用它。在-type f中使用find可以防止这种情况发生。
由于您提到了修改，您可以通过破坏其固件来轻松嵌入嵌入式设备，该固件可通过/dev/mtd*访问。在某些情况下，如果没有一些非常极端的措施，就无法从这种腐败中恢复过来。
答案 1 :(得分：5)
grep有一个--exclude-dir = dir选项，可用于避免/ proc和/ sys
我最近使用了一个这样的命令，我只知道参数的名称，我希望在某个配置文件中，但不知道该文件的路径。
cd / && grep -rI --exclude-dir=proc --exclude-dir=sys pattern *