Como posso excluir todas as mensagens de "permissão negada" de "localizar"?

Preciso ocultar todas as mensagens de permissão negada de:

find . > files_and_folders

Estou experimentando quando essa mensagem surge. Preciso reunir todas as pastas e arquivos para os quais não surgem.

É possível direcionar os níveis de permissão para o files_and_foldersarquivo?

Como ocultar os erros ao mesmo tempo?

<sup>Nota:
* Essa resposta provavelmente é mais profunda do que o caso de uso justifica e find 2>/dev/nullpode ser boa o suficiente em muitas situações. Pode ainda ser interessante para uma perspectiva de plataforma cruzada e para a discussão de algumas técnicas avançadas de shell, com o objetivo de encontrar uma solução o mais robusta possível, mesmo que os casos evitados possam ser amplamente hipotéticos.
* Se o seu sistema estiver configurado para mostrar mensagens de erro localizadas , prefixe as findchamadas abaixo com LC_ALL=C( LC_ALL=C find ...) para garantir que as mensagens em inglês sejam relatadas, para que grep -v 'Permission denied'funcione conforme o esperado. Invariavelmente, no entanto, quaisquer mensagens de erro que não são exibidas estará então em Inglês também.</sup>

Se seu shell é bashouzsh , existe uma solução robusta e razoavelmente simples , usando apenas findrecursos compatíveis com POSIX ; Embora bashela própria não faça parte do POSIX, a maioria das plataformas Unix modernas vem com ela, tornando esta solução amplamente portátil:

find . > files_and_folders 2> >(grep -v 'Permission denied' >&2)

Nota: Há uma pequena chance de que parte da grepsaída possa chegar após a find conclusão, porque o comando geral não espera o comando interno >(...)terminar. Em bash, você pode impedir isso anexando | catao comando.

• >(...)é uma substituição do processo de saída (raramente usada) que permite redirecionar a saída (neste caso, stderr output ( ) para o stdin do comando interno . Além de e , também os suporta, em princípio , mas tentando combiná-los com o redirecionamento de stderr , como é feito aqui ( ), parece ser silenciosamente ignorado (em ).2>>(...)
bashzshksh2> >(...)ksh 93u+

  • grep -v 'Permission denied'filtra para fora ( -v) todas as linhas (do findfluxo stderr de comando) que contenham a frase Permission deniede saídas das linhas restantes para stderr ( >&2).

Esta abordagem é:

• robusto : grepé aplicado apenas a mensagens de erro (e não a uma combinação de caminhos de arquivos e mensagens de erro, potencialmente levando a falsos positivos) e mensagens de erro que não sejam negadas pela permissão são passadas para o stderr.

• efeito colateral free : findo código de saída é preservado: a incapacidade de acessar pelo menos um dos itens do sistema de arquivos encontrados resulta em código de saída 1(embora isso não indique se ocorreram outros erros além dos negados pela permissão).

Soluções compatíveis com POSIX:

As soluções totalmente compatíveis com POSIX têm limitações ou exigem trabalho adicional.

Se finda saída deve ser capturada em um arquivo de qualquer maneira (ou suprimida por completo), a solução baseada em pipeline da resposta de Jonathan Leffler é simples, robusta e compatível com POSIX:

find . 2>&1 >files_and_folders | grep -v 'Permission denied' >&2

Observe que a ordem dos redirecionamentos é importante: 2>&1deve vir primeiro .

A captura de saída stdout em um arquivo antecipadamente permite 2>&1enviar apenas mensagens de erro pelo pipeline, que greppode operar sem ambiguidade.

A única desvantagem é que o código de saída geral será do grepcomando , não do comandofind , o que significa: se não houver nenhum erro ou apenas erros de permissão negada, o código de saída será 1( falha de sinalização ), caso contrário ( erros diferentes dos negados pela permissão) 0- que é o oposto da intenção.
Dito isso, findo código de saída raramente é usado de qualquer maneira , pois muitas vezes transmite pouca informação além de falhas fundamentais , como a passagem de um caminho inexistente.
No entanto, o caso específico de apenas algunsdos caminhos de entrada inacessíveis devido à falta de permissões, é refletido no findcódigo de saída (no GNU e no BSD find): se ocorrer um erro de permissão negada para qualquer um dos arquivos processados, o código de saída será definido como 1.

A seguinte variação aborda isso:

find . 2>&1 >files_and_folders | { grep -v 'Permission denied' >&2; [ $? -eq 1 ]; }

Agora, o código de saída indica se ocorreu algum erro diferente Permission denied : 1caso 0contrário , caso contrário.
Em outras palavras: o código de saída agora reflete a verdadeira intenção do comando: success ( 0) é relatado, se nenhum erro ou apenas erros com permissão negada ocorrerem.
Isso é sem dúvida ainda melhor do que apenas passar findo código de saída, como na solução na parte superior.

gniourf_gniourf nos comentários propõe uma generalização (ainda compatível com POSIX) desta solução usando redirecionamentos sofisticados , que funcionam mesmo com o comportamento padrão de imprimir os caminhos de arquivo no stdout :

{ find . 3>&2 2>&1 1>&3 | grep -v 'Permission denied' >&3; } 3>&2 2>&1

Em resumo: o descritor de arquivo personalizado 3é usado para trocar temporariamente stdout ( 1) e stderr ( 2), para que somente as mensagens de erro possam ser canalizadas grepvia stdout.

Sem esses redirecionamentos, os dados (caminhos do arquivo) e as mensagens de erro seriam canalizados para o grepstdout e grep, portanto, não seriam capazes de distinguir entre a mensagem de erro Permission denied e um arquivo (hipotético) cujo nome contém a frase Permission denied.

Como na primeira solução, no entanto, o código de saída relatado será grep, e não find, mas a mesma correção acima pode ser aplicada.

Notas sobre as respostas existentes:

• Há vários pontos a serem observados sobre a resposta de Michael Brux , find . ! -readable -prune -o -print:

  • Requer GNU find ; notavelmente, não funcionará no macOS. Obviamente, se você precisar apenas do comando para trabalhar com o GNU find, isso não será um problema para você.

  • Alguns Permission deniederros ainda podem surgir: find ! -readable -prunerelata esses erros para os itens filhos de diretórios para os quais o usuário atual tem rpermissão, mas não possui permissão x(executável). O motivo é que, como o próprio diretório é legível, -prunenão é executado e a tentativa de descer para esse diretório aciona as mensagens de erro. Dito isto, o caso típico é a rfalta de permissão.

  • Nota: O ponto a seguir é uma questão de filosofia e / ou caso de uso específico, e você pode decidir que não é relevante para você e que o comando se adapta bem às suas necessidades, especialmente se simplesmente imprimir os caminhos for o que você faz:

    • Se você conceituar a filtragem das mensagens de erro negadas por permissão como uma tarefa separada que deseja aplicar a qualquer find comando, a abordagem oposta de impedir proativamente os erros negados por permissão requer a introdução de "ruído" no findcomando, que também introduz complexidade e armadilhas lógicas .
    • Por exemplo, o comentário mais votado na resposta de Michael (até o momento em que este artigo foi escrito) tenta mostrar como estender o comando incluindo um -namefiltro, da seguinte forma:
      find . ! -readable -prune -o -name '*.txt'
      Isso, no entanto, não funciona conforme o esperado, porque a -printação à direita é necessária (uma explicação pode ser encontrada nesta resposta ). Essas sutilezas podem introduzir bugs.

• A primeira solução na resposta de Jonathan Leffler , find . 2>/dev/null > files_and_folderscomo ele mesmo afirma, cegamente silencia todas as mensagens de erro (e a solução é complicada e não totalmente robusto, como ele também explica). Pragmaticamente falando , no entanto, é a solução mais simples , pois você pode se contentar em supor que todo e qualquer erro esteja relacionado à permissão.

• A resposta de névoa , sudo find . > files_and_folders, é conciso e pragmático, mas mal aconselhado para qualquer outra coisa do que simplesmente imprimir nomes de arquivos , por razões de segurança: porque você está executando como a raiz do usuário, "o risco de ter todo o seu sistema a ser confuso por um erro no achado ou uma versão mal-intencionada ou uma invocação incorreta que escreve algo inesperadamente, o que não poderia acontecer se você executasse isso com privilégios normais "(de um comentário sobre a resposta da névoa por triplicado ).

• A 2ª solução na resposta de viraptor , find . 2>&1 | grep -v 'Permission denied' > some_filecorre o risco de falsos positivos (devido ao envio de uma mistura de stdout e stderr através do gasoduto), e, potencialmente, ao invés de relatar não erros negou--permission via stderr, captura-los ao lado dos caminhos de saída no arquivo de saída.

Usar:

find . 2>/dev/null > files_and_folders

Isso oculta não apenas os Permission deniederros, é claro, mas todas as mensagens de erro.

Se você realmente deseja manter outros erros possíveis, como muitos saltos em um link simbólico, mas não a permissão negada, provavelmente precisará adivinhar que não possui muitos arquivos chamados 'permissão negada' e tentar:

find . 2>&1 | grep -v 'Permission denied' > files_and_folders

Se você deseja estritamente filtrar apenas o erro padrão, pode usar a construção mais elaborada:

find . 2>&1 > files_and_folders | grep -v 'Permission denied' >&2

O I / O redirecionamento no findcomando é: 2>&1 > files_and_folders |. O canal redireciona a saída padrão para o grepcomando e é aplicado primeiro. O 2>&1erro padrão é enviado para o mesmo local da saída padrão (o tubo). O > files_and_foldersenvia saída padrão (mas não o erro padrão) para um arquivo. O resultado líquido é que as mensagens gravadas com erro padrão são enviadas pelo canal e a saída regular de findé gravada no arquivo. Os grepfiltros filtram a saída padrão (você pode decidir o quão seletiva você deseja que seja e pode ter que alterar a ortografia dependendo do código de idioma e do sistema operacional) e o final>&2significa que as mensagens de erro sobreviventes (gravadas na saída padrão) voltam ao erro padrão mais uma vez. O redirecionamento final pode ser considerado opcional no terminal, mas seria uma boa idéia usá-lo em um script para que as mensagens de erro apareçam no erro padrão.

Existem inúmeras variações sobre esse tema, dependendo do que você deseja fazer. Isso funcionará em qualquer variante do Unix com qualquer derivado de shell Bourne (Bash, Korn, ...) e qualquer versão do POSIX compatível com find.

Se você deseja se adaptar à versão específica de findseu sistema, pode haver opções alternativas disponíveis. O GNU, findem particular, possui inúmeras opções não disponíveis em outras versões - veja a resposta atualmente aceita para um desses conjuntos de opções.

Usar:

find . ! -readable -prune -o -print

ou mais geralmente

find <paths> ! -readable -prune -o <other conditions like -name> -print

• para evitar "permissão negada"
• E NÃO suprimir (outras) mensagens de erro
• E obtenha o status de saída 0 ("todos os arquivos foram processados ​​com sucesso")

Trabalha com: find (GNU findutils) 4.4.2. Fundo:

• O -readableteste corresponde aos arquivos legíveis. O !operador retorna verdadeiro, quando teste é falso. E ! -readablecorresponde a diretórios não legíveis (& arquivos).
• A -pruneação não desce no diretório
• ! -readable -prune pode ser traduzido para: se o diretório não estiver legível, não desça nele.
• O -readableteste leva em consideração as listas de controle de acesso e outros artefatos de permissões que o -permteste ignora.

Veja também find(1) a página de manual para muitos mais detalhes.

Se você deseja iniciar a pesquisa a partir da raiz "/", provavelmente verá resultados como:

find: /./proc/1731/fdinfo: Permission denied
find: /./proc/2032/task/2032/fd: Permission denied

É por causa da permissão. Para resolver isso:

1. Você pode usar o comando sudo:

   sudo find /. -name 'toBeSearched.file'

Ele pede a senha do super usuário, quando digitar a senha, você verá o resultado que realmente deseja. Se você não tem permissão para usar o comando sudo, o que significa que você não tem uma senha de superusuário, primeiro peça ao administrador do sistema para adicioná-lo ao arquivo sudoers.

2. Você pode usar o redirecionamento da Saída de erro padrão de (geralmente exibição / tela) para algum arquivo e evitar ver as mensagens de erro na tela! redirecione para um arquivo especial / dev / null:

   find /. -name 'toBeSearched.file' 2>/dev/null

3. Você pode usar o redirecionamento da Saída de erro padrão de (geralmente exibição / tela) para a saída padrão (geralmente exibição / tela) e depois canalizar com o comando grep com o parâmetro -v "invert" para não ver as linhas de saída com 'Permissão negada' pares de palavras:

   find /. -name 'toBeSearched.file' 2>&1 | grep -v 'Permission denied'

Eu tive que usar:

find / -name expect 2>/dev/null

especificando o nome do que eu queria encontrar e dizendo para redirecionar todos os erros para / dev / null

espera ser o local do programa esperado que eu estava procurando.

Tubulação stderrpara /dev/nullusando 2> / dev / null

find . -name '...' 2>/dev/null

Você também pode usar os predicados -perme -prunepara evitar descer para diretórios ilegíveis (consulte também Como remover instruções de impressão com "permissão negada" do programa find? - Unix e Linux Stack Exchange ):

find . -type d ! -perm -g+r,u+r,o+r -prune -o -print > files_and_folders

Redirecionar erro padrão. Por exemplo, se você estiver usando o bash em uma máquina unix, poderá redirecionar o erro padrão para / dev / null assim:

find . 2>/dev/null >files_and_folders

Embora as abordagens acima não tratem do caso para o Mac OS X, porque o Mac Os X não suporta -readablecomutadores, é assim que você pode evitar erros de 'permissão negada' na saída. Isso pode ajudar alguém.

find / -type f -name "your_pattern" 2>/dev/null.

Se você estiver usando algum outro comando com find, por exemplo, para encontrar o tamanho dos arquivos de determinado padrão em um diretório 2>/dev/null, ainda funcionará como mostrado abaixo.

find . -type f -name "your_pattern" -exec du -ch {} + 2>/dev/null | grep total$.

Isso retornará o tamanho total dos arquivos de um determinado padrão. Observe o 2>/dev/nullcomando no final do comando find.

Esses erros são impressos na saída de erro padrão (fd 2). Para filtrá-los, basta redirecionar todos os erros para / dev / null:

find . 2>/dev/null > some_file

ou primeiro, junte-se ao stderr e ao stdout e, em seguida, salve esses erros específicos:

find . 2>&1 | grep -v 'Permission denied' > some_file

Resposta simples:

find . > files_and_folders 2>&-

2>&-fecha ( -) o descritor de arquivo de erro padrão ( 2) para que todas as mensagens de erro sejam silenciadas.

• O código de saída ainda será 1se algum Permission deniederro ' ' seria impresso

Resposta robusta para o GNU find:

find . -type d \! \( -readable -executable \) -prune -print -o -print > files_and_folders

Passe opções extras para findisso -prune(evite a descida para), mas ainda -printqualquer diretório ( ) que não ( ) tenha permissões e , ou ( ) qualquer outro arquivo.-typed\!-readable-executable-o-print

• -readablee -executableopções são extensões GNU, não fazem parte do padrão POSIX
• Ainda pode retornar ' Permission denied' em arquivos anormais / corrompidos (por exemplo, consulte o relatório de bug que afeta os sistemas de arquivos montados em contêiner usando lxcfs<v2.0.5)

Resposta robusta que funciona com qualquer compatível com POSIX find(GNU, OSX / BSD, etc)

{ LC_ALL=C find . 3>&2 2>&1 1>&3 > files_and_folders | grep -v 'Permission denied'; [ $? = 1 ]; } 3>&2 2>&1

Use um pipeline para transmitir o fluxo de erro padrão grep, removendo todas as linhas que contêm a 'Permission denied'sequência.

LC_ALL=Cdefine o locale POSIX usando uma variável de ambiente , 3>&2 2>&1 1>&3e 3>&2 2>&1 descritores de arquivos duplicados para canalizar o fluxo de erros padrão para grepe [ $? = 1 ]usos []para inverter o código de erro retornado por grepaproximar o comportamento original de find.

• Também filtrará quaisquer 'Permission denied'erros devido ao redirecionamento de saída (por exemplo, se o files_and_foldersarquivo em si não for gravável)

Para evitar apenas os avisos de permissão negada, diga ao find para ignorar os arquivos ilegíveis, removendo-os da pesquisa. Adicione uma expressão como OR à sua localização, como

find / \! -readable -prune -o -name '*.jbd' -ls

Isso geralmente diz para (corresponder a um arquivo ilegível e removê-lo da lista) OR (corresponder a um nome como * .jbd e exibi-lo [com ls]) . (Lembre-se de que, por padrão, as expressões são AND juntas, a menos que você use -or.) Você precisa de -ls na segunda expressão, caso contrário, a localização pode adicionar uma ação padrão para mostrar uma das correspondências, o que também mostrará todos os arquivos ilegíveis .

Mas se você está procurando arquivos reais no seu sistema, geralmente não há razão para procurar no / dev, que possui muitos arquivos, portanto, você deve adicionar uma expressão que exclua esse diretório, como:

find / -mount \! -readable -prune  -o  -path /dev -prune  -o  -name '*.jbd' -ls

Então (corresponda arquivo ilegível e remova da lista) OR (corresponda ao caminho / dev e remova da lista) OR (corresponda ao arquivo como * .jbd e exiba-o) .

usar

sudo find / -name file.txt

É estúpido (porque você eleva a pesquisa) e não seguro, mas muito mais curto para escrever.

Nenhuma das respostas acima funcionou para mim. Tudo o que encontro na Internet se concentra em: ocultar erros. Nenhum lida adequadamente com o código de retorno / código de saída do processo. Uso o comando find nos scripts do bash para localizar alguns diretórios e depois inspecionar o conteúdo deles. Eu avalio o comando encontrar sucesso usando o código de saída: um valor zero funciona, caso contrário, falha.

A resposta fornecida acima por Michael Brux funciona algumas vezes. Mas eu tenho um cenário em que falha! Eu descobri o problema e o consertei. Preciso remover arquivos quando:

it is a directory AND has no read access AND/OR has no execute access

Veja a questão principal aqui é: AND / OR. Uma boa sequência de condições sugerida que li é:

-type d ! -readable ! -executable -prune

Isso nem sempre funciona. Isso significa que uma ameixa é acionada quando uma correspondência é:

it is directory AND no read access AND no execute access

Essa sequência de expressões falha quando o acesso de leitura é concedido, mas nenhum acesso de execução é.

Após alguns testes, percebi isso e mudei minha solução de script de shell para:

bom encontrar / home * / -maxdepth 5 -seguir \
    \ (-tipo d -a ! \ (-readable -a -executable \) \) -une -une \
    -o \
    \ (-type d -a -readable -a - executável -a -name "$ {m_find_name}" \) -print

A chave aqui é colocar o "não verdadeiro" para uma expressão combinada:

has read access AND has execute access

Caso contrário, ele não terá acesso total, o que significa: removê-lo. Isso provou funcionar para mim em um cenário em que as soluções sugeridas anteriormente falharam.

A seguir, forneço detalhes técnicos para perguntas na seção de comentários. Peço desculpas se os detalhes forem excessivos.

• Por que usar o comando nice? Eu tenho a ideia aqui . Inicialmente, pensei que seria bom reduzir a prioridade do processo ao procurar um sistema de arquivos inteiro. Percebi que não faz sentido para mim, pois meu script é limitado a poucos diretórios. Reduzi -maxdepth para 3.
• ¿Por que pesquisar em / home * /? Isso não é relevante para este segmento. Eu instalo todos os aplicativos manualmente através da compilação do código fonte com usuários não privilegiados (não root). Eles são instalados em "/ home". Posso ter vários binários e versões vivendo juntos. Preciso localizar todos os diretórios, inspecionar e fazer backup de maneira mestre-escravo. Eu posso ter mais de um "/ home" (vários discos sendo executados em um servidor dedicado).
• Por que usar -follow? Os usuários podem criar links simbólicos para diretórios. É utilidade depende, eu preciso manter o registro dos caminhos absolutos encontrados.

Você pode usar o grep -v invert-match

-v, --invert-match        select non-matching lines

como isso:

find . > files_and_folders
cat files_and_folders | grep -v "permission denied" > files_and_folders

Deve à magia

- = Para MacOS = -

Faça um novo comando usando o alias: basta adicionar na linha ~ / .bash_profile:

alias search='find / -name $file 2>/dev/null'

e na nova janela do Terminal, você pode chamá-lo:

$ file=<filename or mask>; search

por exemplo:

$ arquivo = etc; procurar

Se você estiver usando CSH ou TCSH, aqui está uma solução:

( find . > files_and_folders ) >& /dev/null

Se você deseja saída para o terminal:

( find . > /dev/tty ) >& /dev/null

No entanto, como a FAQ "csh-whynot" descreve, você não deve usar o CSH.