Linux: localiza | xargs grep tem limitações?

Question

Eu, historicamente, fiz algo como:

find . 2>/dev/null | xargs grep -i something_to_find 2>/dev/null

Se meu pwd for barfoo ( /foo/bar/baz/foofoo/foobar/foobaz/barfoo ), ele encontrará correspondências. No entanto, se eu cd to /foo , ele não encontrar mais as correspondências.

Condições:

• permissões são todas 775
• os diretórios não são links simbólicos
• eles estão todos no mesmo sistema de arquivos / servidor

Então, estou curioso para saber se há um -maxdepth padrão que é aplicado para encontrar, ou existem outras restrições sobre por que isso não funcionaria?

Informações adicionais:

Alguns ótimos comentários foram postados. Aqui estão algumas informações adicionais:

• isto é para o GNU, não para o POSIX
• find --version : GNU encontra a versão 4.2.27
• grep --version : (GNU grep) 2.5.1
• xargs --version : GNU xargs versão 4.2.27
• remover o redirecionamento do STDERR não tem relação com o resultado, ou a falta dele
• o caminho para os arquivos em barfoo (conhecidos para o trabalho) não tem espaços, no entanto, os arquivos em outros diretórios em /foo/bar podem ter espaços; no entanto, não vejo como isso seria problemático
• Eu percebo que não era específico no caminho, mas todos esses diretórios são bem conhecidos, não devem ser confundidos com nenhum dispositivo

Descoberta interessante:

O primeiro não funciona, mas o segundo não:

1. find . -type f | xargs grep -i something_to_find
2. find . -type f -name "*.ext" | xargs grep -i something_to_find

Ainda mais estranho é que -name "*.*" não funcione, a extensão do arquivo tem que ser dada; o que poderia ser problemático ao procurar por algo.

Eu estou querendo saber se há terminação após uma contagem máxima de erros ou tamanho máximo do buffer. Eu sei que existem muitos arquivos nesses diretórios, mas o fato de funcionar ao especificar o tipo de arquivo (limitar os resultados) é interessante.

    

Answer 1

Diretórios com nomes que contêm espaços, visíveis de /foo/bar e não de barfoo , são os prováveis culpados. xargs divide sua saída por espaços e também interpreta citações, barras invertidas e até mesmo o caractere _ - consulte manual para detalhes, portanto os espaços em branco nos nomes de arquivos ou diretórios fazem com que ele passe nomes de arquivos incompletos para grep .

Para contornar esse problema, use find -print0 em conjunto com xargs -0 , assim:

find . -print0 2>/dev/null | xargs -0 grep -i something_to_find 2>/dev/null

A opção -print0 informa find para separar nomes de arquivos com um caractere binário 0, que não pode aparecer em um nome de arquivo válido. A opção -0 correspondente diz à parte para usar o mesmo caractere que o separador e também para não interpretar citações e barras invertidas.

    

Answer 2

Tendo em conta a sua edição mais recente, gostaria de o apontar novamente para o meu comentário:

Since you mention "same server": Is there any chance that special files like /proc/kcore or /dev/zero are anywhere in the path? That would certainly stop grep from going any further.....

Uma vez que adicionar uma extensão produz resultados diferentes da execução sem esse tipo de espaços de regras como o culpado.

    

Answer 3

Tente

grep -r something_to_find 2>/dev/null

"grep -r ..." pesquisará todos os arquivos recursivamente a partir de $ PWD.

    

Answer 4

Tente isto:

find . -type f -print0 | tee /tmp/file-list | xargs -0 egrep whatever

A / tmp / file-list (visualiza com algo que não se importa com nulos) contém seu (s) arquivo (s) desejado (s)? Se não, é um problema de localização. Se sim, é uma questão de xargs.

Eu intencionalmente não eliminei os erros. Eles podem ser úteis.