我正在搜索文件系统并使用grep.我看到一切正常,直到出现此错误:
Grep: /proc/sysrq-trigger: Input/output error
我已经在网上的各个地方找到了信息,其他地方遇到了同样的问题,但是没有任何地方可行的.我尝试了2>/dev/null,它压制了错误,但没有"跳过文件",这实际上是我希望它会做的.相反,它只是停止进程(这是一个利用grep的find/sed进程).我认为有一种方法可以使用grep指定要排除的文件,但我希望可能有更强大和更优雅的解决方案.
thk*_*ala 16
听起来好像是在递归搜索整个文件系统层次结构.这在大多数系统上都无法正常工作.
在Linux至少/proc和/sys在虚拟文件系统-它们不符合在磁盘上的实际文件.在特殊的文件/dev,也没有实际的文件-它们对应于一些系统上的设备,如硬盘,输入设备等修改的-和,偶尔,甚至读-文件在任何这些目录中不应该发生在一个不受控制方式,因为你可以崩溃内核,破坏你的文件系统,甚至造成你的硬件永久性损坏.
由于您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:
如果读取为旧的内核曾经崩溃.我相信这不再发生了,但我已经遇到过这个问题,因为它是在2.4.x内核系列中引入的,它偶尔会再次弹出,所以我没心情去实际测试它.../proc/kcoreroot/proc/kcore
通过其设备节点读取块设备/dev/会严重降低该设备上的任何其他操作,因为它会绕过VFS和各种缓存.想象一下,例如,直接读取6TB RAID-5分区,而其他进程尝试通过已安装的文件系统正确使用它.使用-type fin find应该防止这种情况发生.
由于您提到了修改,您可以通过破坏其固件来轻松嵌入嵌入式设备,该固件可通过以下方式访问/dev/mtd*.在某些情况下,如果没有一些极端的措施,就无法从这种腐败中恢复过来
grep有一个--exclude-dir = dir选项,可用于避免/ proc和/ sys
我最近使用了这样的命令,我只知道参数的名称,我希望在某个配置文件中,但不知道该文件的路径.
cd / && grep -rI --exclude-dir=proc --exclude-dir=sys pattern *