我正在搜索文件系統並使用grep。我看到的一切工作，直到出現這樣的錯誤：grep：/ proc/sysrq-trigger：輸入/輸出錯誤
Grep: /proc/sysrq-trigger: Input/output error
我發現在網上，別人都來翻過了同樣的問題，各個地方的信息，但無處真的是有什麼事情的工作。我嘗試了2>/dev/null，它可以抑制錯誤，但不會'跳過文件'，這實際上是我希望它會做的。相反，它只是停止進程（這是一個利用grep的find/sed進程）。我認爲有一種方法可以使用grep指定要排除的文件，但我希望可能有更強大和更優雅的解決方案。
聽起來好像您是遞歸搜索整個文件系統層次結構。這在大多數系統上無法按預期工作。
在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
，因爲你需要微調的find輸出可以使用盡可能多的-path和/或-prune選項。不過，我建議你先檢查它的輸出，然後再將它傳遞到管道中的任何後期階段。
編輯：
這裏有以不受控制的方式訪問特定的文件時造成的損害的一些例子 - 通常爲root：
舊版內核used to crash如果/proc/kcore被讀爲root。我認爲這不再發生，但是我自從/proc/kcore被引入到2.4.x內核系列和它的occasionally pops up again之後，所以我沒有心情去實際測試它...
讀取塊設備通過其設備節點/dev/可能會嚴重減慢該設備上的其他任何操作，因爲它會繞過VFS和各種緩存。想象一下，例如，直接讀取6TB RAID-5部分，而其他進程則嘗試通過已安裝的文件系統正確使用它。使用-type f在find應該防止發生這種情況。
由於您提到的修改，您可以通過破壞其固件，通過/dev/mtd*可以輕鬆地製作嵌入式設備。在某些情況下，如果沒有一些非常極端的措施，就無法從這種腐敗中恢復過來
我明白，我不知道你可能會因爲閱讀而損壞它該文件 - 我想這可能是由於阻止其他重要進程的訪問？感謝您的詳細回覆，非常感謝。例如，我可以將更多排除的路徑鏈接在一起！ -path'/ proc/*！ -path'/ sys/*'等？ – user1166981 2012-02-29 22:06:47
1.有一些文件在以root身份進行讀取時歷史上會導致問題。當讀取'/ proc/kcore'時，我的一箇舊系統崩潰了 - 如果有東西試圖直接讀取我的RAID陣列設備（儘管'-type f'至少應該防止這種情況），這會非常惱人* – thkala 2012-02-29 22:11:46
2.你不只是閱讀，你提到的修改。現在'sed -i'通常會在替換原始文件之前寫入臨時文件，以保護不可刪除的文件，但其他任何方法都可以輕鬆修改原始文件，導致*很多*損害。 – thkala 2012-02-29 22:14:18
的grep有，您可以使用，以避免/ proc和/ SYS
我用這樣的命令最近，我只知道一個參數的名稱的--exclude-DIR = DIR選項我期望在某個配置文件中，但不知道文件的路徑。
cd/&& grep -rI --exclude-dir=proc --exclude-dir=sys pattern *
所以使用'find $ whatever！ -wholename「/ proc/sysrq-trigger」'？ – 2012-02-26 11:21:54
*爲什麼*你在'/ proc'中遞歸讀取文件？如果您以更廣泛的方式告訴我們您想要做什麼，我們可能會幫助您更多。 – thkala 2012-02-26 18:45:23
@thkala試圖搜索具有特定字符串的文件，然後刪除該文件的全部內容。 – user1166981 2012-02-29 21:33:32