Quais são as razões exatas 'grep' on / proc e raw disc é uma má ideia?

Question

Eu corri grep -r "searchphrase" / hoje e isso não funcionou. Eu fiz algumas pesquisas e achei que find / -xdev -type f -print0 | xargs -0 grep -H "searchphrase" era a abordagem correta.

Eu entendo /proc e discos como /dev/sda1 são culpados por um grep não bem-sucedido.

Eu adoraria um profundo conhecimento técnico sobre o "porquê". Eu acho que alguns links dentro de /proc criam loops infinitos quando percorridos, e eu leio há mais razões, mas nada específico.

Além disso, o que acontece quando um disco bruto é encontrado? Os dados binários (que podem ser acessados em /dev/sda1 , até onde eu sei?) Não serão interpretados, pois somente um mount com um tipo de sistema de arquivos torna os dados do disco inteligíveis? Seria, portanto, ainda possível grep para uma string binária?

    

Answer 1

Sim, você pode grep /dev/sda1 e /proc , mas provavelmente não deseja. Mais detalhadamente:

1. Sim, você pode executar grep o conteúdo binário de /dev/sda1 . Mas, com discos rígidos grandes e modernos, isso levará muito tempo e o resultado provavelmente não será útil.

2. Sim, você pode usar o conteúdo de /proc , mas esteja ciente de que a memória do seu computador está mapeada como arquivos. Em um computador moderno com gigabytes de RAM, isso levará muito tempo para o grep e, novamente, o resultado provavelmente não será útil.

Como uma exceção, se você estiver procurando dados em um disco rígido com um sistema de arquivos danificado, poderá executar grep something /dev/sda1 como parte de uma tentativa de recuperar os dados do arquivo.

Outros arquivos problemáticos em /dev

Os discos rígidos e as partições do disco rígido em /dev podem ser, se houver paciência suficiente, grepped. Outros arquivos (dica de chapéu: user2313067 ), no entanto, podem causar problemas:

1. /dev/zero é um arquivo de tamanho infinito. Felizmente, grep (pelo menos a versão GNU) é inteligente o suficiente para ignorá-lo:

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

2. /dev/random e /dev/urandom também são infinitos. O comando grep something /dev/random será executado para sempre, a menos que grep seja sinalizado para parar.

   Pode ser útil para grep /dev/urandom ao gerar senhas. Para obter, por exemplo, cinco caracteres alfanuméricos aleatórios:

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

   Isto não é infinito porque, depois de ter recebido caracteres suficientes, head fecha o pipe fazendo com que o grep termine.

Loops infinitos

"...links ... create infinite loops when traversed..."

O Grep (pelo menos a versão GNU) é inteligente o suficiente para não fazer isso. Vamos considerar dois casos:

1. Com a opção -r , o grep não segue links simbólicos, a menos que eles sejam explicitamente especificados na linha de comando. Por isso, loops infinitos não são possíveis.

2. Com a opção -R , o grep faz seguir links simbólicos, mas os verifica e se recusa a ser pego em um loop. Para ilustrar:

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

Excluindo diretórios problemáticos de grep -r

Como um aparte, grep fornece um recurso limitado para impedir que o grep pesquise certos arquivos ou diretórios. Por exemplo, você pode excluir todos os diretórios denominados proc , sys e dev da pesquisa recursiva do grep com:

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

Como alternativa, podemos excluir proc , sys e dev usando os globs estendidos do bash:

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