¿Cuáles son las razones exactas por las que `grep` en / proc y discos en bruto son una mala idea?

Corrí grep -r "searchphrase" /hoy y eso no funcionó. Investigué un poco y descubrí find / -xdev -type f -print0 | xargs -0 grep -H "searchphrase"que era el enfoque correcto.

Recojo /procy discos como /dev/sda1son los culpables de un grep no exitoso.

Me encantaría tener una formación técnica profunda sobre el "por qué". Creo que algunos enlaces dentro /proccrean bucles infinitos cuando se atraviesan, y leí que hay más razones, pero nada específico.

Además, ¿qué sucede cuando un disco sin procesar está agrietado? ¿ /dev/sda1No se pueden interpretar los datos binarios (a los que se puede acceder , por lo que sé), ya que solo un mounttipo de sistema de archivos hace que los datos del disco sean inteligibles? ¿Sería posible, por lo tanto, grep para una cadena binaria?

Sí, puedes grep /dev/sda1y /procprobablemente no quieras. Con más detalle:

1. Sí, puede ejecutar grep el contenido binario de /dev/sda1. Pero, con los discos duros grandes modernos, esto llevará mucho tiempo y es probable que el resultado no sea útil.

2. Sí, puede manipular el contenido, /procpero tenga en cuenta que la memoria de su computadora está asignada allí como archivos. En una computadora moderna con gigabytes de RAM, esto llevará mucho tiempo y, nuevamente, el resultado probablemente no sea útil.

Como excepción, si está buscando datos en un disco duro con un sistema de archivos dañado, puede ejecutarlo grep something /dev/sda1como parte de un intento de recuperar los datos del archivo.

Otros archivos problemáticos en /dev

Los discos duros y las particiones del disco duro debajo /devpueden, si uno tiene suficiente paciencia, agrietarse. Otros archivos (hat hat: user2313067 ), sin embargo, pueden causar problemas:

1. /dev/zeroes un archivo de longitud infinita. Afortunadamente, grep(al menos la versión GNU) es lo suficientemente inteligente como para omitirla:

   $ grep something /dev/zero
   grep: input is too large to count
   

2. /dev/randomy /dev/urandomtambién son infinitos. El comando grep something /dev/randomse ejecutará para siempre a menos que grepse indique que se detenga.

   Puede ser útil para grep /dev/urandomal generar contraseñas. Para obtener, por ejemplo, cinco caracteres alfanuméricos aleatorios:

   $ grep --text -o '[[:alnum:]]' /dev/urandom | head -c 10
   G
   4
   n
   X
   2
   

   Esto no es infinito porque, después de haber recibido suficientes caracteres, headcierra la tubería haciendo que grep termine.

Bucles infinitos

"... los enlaces ... crean bucles infinitos cuando se atraviesan ..."

Grep (al menos la versión GNU) es lo suficientemente inteligente como para no hacer eso. Consideremos dos casos:

1. Con la -ropción, grep no sigue enlaces simbólicos a menos que se especifiquen explícitamente en la línea de comando. Por lo tanto, los bucles infinitos no son posibles.

2. Con la -Ropción, grep hace seguir enlaces simbólicos sino que los cheques y se niega a quedar atrapado en un bucle. Para ilustrar:

   $ mkdir a
   $ ln -s ../ a/b
   $ grep -R something .
   grep: warning: ./a/b: recursive directory loop
   

Excluyendo directorios problemáticos de grep -r

Por otro lado, grepproporciona una facilidad limitada para evitar que grep busque ciertos archivos o directorios. Por ejemplo, puede excluir todos los directorios nombrados proc, sysy devde búsqueda recursiva de grep con:

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

Alternativamente, podemos excluir proc, sysy devel uso de globos largos de bash:

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