Quelles sont les raisons exactes pour lesquelles `grep` sur / proc et les disques bruts est une mauvaise idée?

J'ai couru grep -r "searchphrase" /aujourd'hui et cela n'a pas fonctionné. J'ai fait quelques recherches et j'ai trouvé que find / -xdev -type f -print0 | xargs -0 grep -H "searchphrase"c'était la bonne approche.

Je rassemble /procet les disques comme /dev/sda1sont les coupables d'un grep non réussi.

J'aimerais beaucoup de connaissances techniques approfondies sur le "pourquoi". Je pense que certains liens à l'intérieur /proccréent des boucles infinies lorsqu'ils sont parcourus, et j'ai lu qu'il y a plus de raisons, mais rien de spécifique.

De plus, que se passe-t-il lorsqu'un disque brut est pris en charge? Les données binaires (qui sont accessibles /dev/sda1pour autant que je sache?) Ne peuvent-elles pas être interprétées, car seul un mounttype de système de fichiers rend les données du disque intelligibles? Serait-il donc toujours possible de rechercher une chaîne binaire?

Oui, vous pouvez grep /dev/sda1et /procvous ne voulez probablement pas. Plus en détail:

1. Oui, vous pouvez exécuter grep le contenu binaire de /dev/sda1. Mais, avec les grands disques durs modernes, cela prendra très longtemps et le résultat ne sera probablement pas utile.

2. Oui, vous pouvez saisir le contenu de /procmais sachez que la mémoire de votre ordinateur y est mappée sous forme de fichiers. Sur un ordinateur moderne avec des gigaoctets de RAM, cela prendra beaucoup de temps à grep et, encore une fois, le résultat ne sera probablement pas utile.

Par exception, si vous recherchez des données sur un disque dur avec un système de fichiers endommagé, vous pouvez exécuter grep something /dev/sda1dans le cadre d'une tentative de récupération des données du fichier.

Autres fichiers problématiques dans /dev

Les disques durs et les partitions de disque dur sous /devpeuvent être, si l'on a assez de patience, grognés. D'autres fichiers (astuce chapeau: user2313067 ) peuvent cependant provoquer des problèmes:

1. /dev/zeroest un fichier de longueur infinie. Heureusement, grep(au moins la version GNU) est assez intelligent pour l'ignorer:

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

2. /dev/randomet /dev/urandomsont également infinis. La commande grep something /dev/randoms'exécutera indéfiniment sauf si elle grepest signalée pour s'arrêter.

   Il peut être utile de grep /dev/urandomlors de la génération de mots de passe. Pour obtenir, par exemple, cinq caractères alphanumériques aléatoires:

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

   Ce n'est pas infini car, après avoir reçu suffisamment de caractères, headferme le canal provoquant la fin de grep.

Boucles infinies

"... les liens ... créent des boucles infinies lorsqu'ils sont parcourus ..."

Grep (au moins la version GNU) est assez intelligent pour ne pas le faire. Prenons deux cas:

1. Avec l' -roption, grep ne suit pas les liens symboliques à moins qu'ils ne soient explicitement spécifiés sur la ligne de commande. Par conséquent, les boucles infinies ne sont pas possibles.

2. Avec l' -Roption grep - t suivre les liens symboliques , mais il les vérifie et refuse de se coincer dans une boucle. Pour illustrer:

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

Exclusion des répertoires problématiques de grep -r

En greppassant , fournit une fonction limitée pour empêcher grep de rechercher certains fichiers ou répertoires. Par exemple, vous pouvez exclure tous les répertoires nommés proc, syset devde la recherche récursive grep avec:

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

Alternativement, nous pouvons exclure proc, syset devutiliser les globs étendus de bash:

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