Каковы точные причины `grep` на /proc и raw дисках - плохая идея?

Question

Я запустил grep -r "searchphrase" / сегодня, и это не сработало. Я провел некоторое исследование и нашел find / -xdev -type f -print0 | xargs -0 grep -H "searchphrase" - правильный подход.

Я понимаю, что /proc и такие диски, как /dev/sda1 являются виновниками неудачного поиска.

Я хотел бы иметь глубокие технические знания о "почему". Я думаю, что некоторые ссылки в /proc создают бесконечные циклы при прохождении, и я прочитал, что есть больше причин, но ничего конкретного.

Кроме того, что происходит, когда очищается необработанный диск? Могут ли двоичные данные (что доступно на /dev/sda1 , насколько я знаю?) не интерпретировать, так как только mount с типом файловой системы делает данные с диска понятными? Следовательно, можно ли использовать grep для двоичной строки?

Answer 1

Да, вы можете использовать grep /dev/sda1 и /proc но, вероятно, не хотите. Более подробно:

1. Да, вы можете запустить grep двоичное содержимое /dev/sda1 . Но с современными большими жесткими дисками это займет очень много времени, и результат вряд ли будет полезным.

2. Да, вы можете получить содержимое /proc но помните, что память вашего компьютера там отображается в виде файлов. На современном компьютере с гигабайтами оперативной памяти, это займет много времени, и, опять же, результат вряд ли будет полезным.

В качестве исключения, если вы ищете данные на жестком диске с поврежденной файловой системой, вы можете запустить grep something /dev/sda1 как часть попытки восстановить данные файла.

Другие проблемные файлы в /dev

Жесткие диски и разделы на жестких дисках в /dev могут быть выделены , если у вас хватит терпения. Другие файлы (например, 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 не получит сигнал об остановке.

   Это может быть полезно для 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 определенных файлов или каталогов. Например, вы можете исключить все каталоги с именами proc , sys и dev из рекурсивного поиска grep с помощью:

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

В качестве альтернативы, мы можем исключить proc , sys и dev используя расширенные глобусы bash:

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