Come posso escludere tutti “autorizzazione negata” messaggi da “trovare”?

https://stackoverflow.com/questions/762348

11-09-2019
|

Domanda

Ho bisogno di nascondere tutti permesso negato messaggi:

find . > files_and_folders

Sto sperimentando quando tale messaggio non si pone.Ho bisogno di raccogliere tutte le cartelle e i file, per cui non si pone.

È possibile indirizzare i livelli di autorizzazione per l' files_and_folders il file?

Come posso nascondere gli errori, allo stesso tempo?

Soluzione

^{Nota:

* Questa risposta, probabilmente, va più in profondità rispetto al caso di utilizzo di warrant, e find 2>/dev/null può essere abbastanza buono in molte situazioni.Si può ancora essere di interesse per un cross-piattaforma di prospettiva e per la discussione di alcuni advanced shell tecniche nell'interesse di trovare una soluzione che è robusto come possibile, anche se i casi protetti possono essere in gran parte ipotetica.

* Se il sistema è configurato per mostrare localizzata messaggi di errore, prefisso il find chiamate seguito con LC_ALL=C (LC_ALL=C find ...) per garantire che Inglese i messaggi vengono segnalati, in modo che grep -v 'Permission denied' funziona come previsto.Invariabilmente, tuttavia, eventuali messaggi di errore fare visualizzati saranno in inglese.}

Se il vostro shell è bash o zsh, c'è una soluzione che è robusto, di essere ragionevolmente semplice, utilizzando solo POSIX-compliant find caratteristiche;mentre bash di per sé non è parte dello standard POSIX, più moderne piattaforme Unix vengono con esso, rendendo questa soluzione ampiamente portatile:

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

Nota:C'è una piccola possibilità che alcuni di grep's di uscita può arrivare dopo find completa, perché il comando generale non attendere che il comando all'interno >(...) per finire.In bash, è possibile evitare questo aggiungendo | cat al comando.

>(...) è un (raramente usato) uscita il processo di sostituzione che permette di reindirizzare l'output (in questo caso, stderr output (2>) per stdin del comando all'interno di >(...).
Oltre a bash e zsh, ksh supporta anche loro in linea di principio, ma cercando di coniugarle con reindirizzamento da stderr, come è fatto qui (2> >(...)), sembra essere ignorata (in ksh 93u+).
- grep -v 'Permission denied' filtri fuori (-v) tutte le linee (dal find comando del flusso stderr) che contengono la frase Permission denied e le uscite le linee rimanenti su stderr (>&2).

Questo approccio è:

robusto: grep viene applicato solo per messaggi di errore (e non una combinazione di percorsi di file e messaggi di errore, che può portare a falsi positivi), i messaggi di errore e altri che il permesso di negazione di quelli che sono passati attraverso, per stderr.
effetti collaterali: find's il codice di uscita è conservato:l'impossibilità di accesso ad almeno uno dei filesystem elementi riscontrati risultati in codice di uscita 1 anche se non te lo dicono se gli errori altri che il permesso di negazione di quelli che si è verificato (troppo)).

POSIX-compliant soluzioni:

Completamente compatibile POSIX soluzioni di avere limitazioni o richiedono un lavoro aggiuntivo.

Se find's di uscita è quello di essere catturati in una file comunque (o del tutto soppressa), quindi la pipeline a base di soluzione Jonathan Leffler risposta è semplice, robusto e POSIX-compliant:

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

Si noti che l'ordine dei reindirizzamenti questioni: 2>&1 deve venire prima.

L'acquisizione di stdout output in un file di fronte permette 2>&1 per inviare solo messaggi di errore attraverso la pipeline, che grep può, quindi, senza ambiguità operare.

Il unico inconveniente è che la nel complesso codice di uscita sarà l' grep comando, non find's, che in questo caso significa:se ci sono no di errori o solo permesso negato errori, il codice di uscita sarà 1 (segnalazione fallimento), in caso contrario (errori di altri che il permesso di negazione di quelli) 0 - che è l'opposto dell'intento.
Detto questo, find's il codice di uscita è raramente usato comunque, come spesso trasmette po ' di informazioni al di là di fondamentale il fallimento, come il passaggio di un percorso non esistente.
Tuttavia, il caso specifico di anche solo alcuni dei percorsi di input essere inaccessibile a causa della mancanza di autorizzazioni è riflette in find's il codice di uscita (sia GNU e BSD find):se per le autorizzazioni-ha negato di errore si verifica per qualsiasi dei file elaborati, il codice di uscita è impostato su 1.

La seguente variazione indirizzi:

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

Ora, il codice di uscita indica se gli eventuali errori diverso Permission denied si è verificato: 1 se è così, 0 altrimenti.
In altre parole:il codice di uscita è ora riflette il vero intento del comando:successo0) viene segnalato, se non ci sono errori o solo permesso negato errori.
Questo è probabilmente anche meglio di un semplice passaggio find's il codice di uscita attraverso, come la soluzione al top.

gniourf_gniourf nei commenti propone una (ancora POSIX-compliant) la generalizzazione di questa soluzione, utilizzando sofisticati reindirizzamenti, che funziona anche con il comportamento predefinito di stampa i percorsi dei file per stdout:

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

In breve:Personalizzato descrittore di file 3 è utilizzato temporaneamente swap stdout (1) e stderr (2), in modo che i messaggi di errore da solo può essere reindirizzato a grep via stdout.

Senza questi reindirizzamenti, sia i dati (i percorsi dei file) e messaggi di errore sarebbe convogliato grep via stdout, e grep quindi non essere in grado di distinguere tra messaggio di errore Permission denied e un (ipotetico) file il cui nome contiene la frase Permission denied.

Come nella prima soluzione, tuttavia, l'uscita di codice riportato sarà grep's, non find's, ma lo stesso il fix di cui sopra può essere applicata.

Note su answers:

Ci sono alcuni punti da notare circa Michael Brux risposta, find . ! -readable -prune -o -print:
- Si richiede GNU find;in particolare, non funziona su macOS.Naturalmente, se avete solo bisogno di mai il comando lavorare con GNU find, questo non sarà un problema per voi.
- Alcuni Permission denied errori ancora superficie: find ! -readable -prune i rapporti di tali errori per il bambino voci di directory per la quale l'utente corrente non dispone di r il permesso, ma manca x (eseguibile) il permesso.Il motivo è che, poiché la directory stessa è leggibile, -prune non viene eseguito, e il tentativo di scendere in che poi directory attiva i messaggi di errore.Detto questo, il tipico caso è che le r il permesso di essere mancanti.
- Nota:Il punto seguente è una questione di filosofia e/o l'uso specifico caso, e si potrebbe decidere che non ti interessa e che il comando si adatta alle vostre esigenze, soprattutto se semplicemente stampa il percorso è tutto ciò che devi fare:
  - Se si concettualizzare il filtraggio dell'autorizzazione negata messaggi di errore di un separato l'attività che si desidera essere in grado di applicare per qualsiasi find comando, quindi l'opposto di un approccio proattivo prevenzione permesso negato errori richiede l'introduzione di "rumore" in find comando, che introduce anche la complessità e la logica insidie.
  - Per esempio, il più votato commento su Michael risposta (come di questa scrittura, tenta di mostrare come estendere il comando, tra cui un -name filtro, come segue:
    find . ! -readable -prune -o -name '*.txt'
    Questo, tuttavia, non non funziona come previsto, perché il finale -print l'azione è richiesto (una spiegazione può essere trovata in questa risposta).Tali sfumature possono introdurre bug.
La prima soluzione Jonathan Leffler risposta, find . 2>/dev/null > files_and_folders, come egli stesso afferma, ciecamente silenzi tutti messaggi di errore (e la soluzione non è ingombrante e non completamente robusto, come ha spiegato anche). Pragmaticamente parlando, tuttavia, è il soluzione più semplice, come si può essere contenuto supporre che qualsiasi e tutti gli errori sarebbe relativi alle autorizzazioni.
nebbia risposta, sudo find . > files_and_folders, è conciso e pragmatico, ma mal consigliato per qualcosa di diverso solo stampa i nomi di file, per motivi di sicurezza:perché si esegue come il root utente, "c'è il rischio che l'intero sistema sta incasinato da un bug nel trovare o dannoso versione, o di una non corretta invocazione che scrive qualcosa di imprevisto, che non potrebbe accadere se si esegue il normale privilegi" (da un commento sulla nebbia risposta da tripleee).
2 ° soluzione viraptor risposta, find . 2>&1 | grep -v 'Permission denied' > some_file si corre il rischio di falsi positivi (grazie all'invio di un mix di stdout e stderr attraverso pipeline), e, potenzialmente, invece di reporting non-permesso negato gli errori di via stderr, li cattura insieme i percorsi di output nel file di output.

Altri suggerimenti

Usa:

find . 2>/dev/null > files_and_folders

Questa nasconde non solo gli errori Permission denied, naturalmente, ma tutti i messaggi di errore.

Se si vuole veramente tenere altri errori possibili, come troppi salti su un link simbolico, ma non quelli di autorizzazione negata, allora si sarebbe probabilmente prendere un volo intuire che non si dispone di molti file chiamati ' permesso negato' e provare:

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

Se si desidera filtrare strettamente errore solo standard, è possibile utilizzare la costruzione più elaborata:

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

La redirezione I / O sul comando find è: 2>&1 > files_and_folders |. Il tubo reindirizza standard output al comando grep e viene applicato per primo. Il 2>&1 invia errore standard nello stesso posto come uscita standard (tubo). Il > files_and_folders invia output standard (ma errore non standard) in un file. Il risultato netto è che i messaggi scritti errore standard vengono inviati giù per il tubo e l'uscita regolare del find viene scritto nel file. Il grep filtra l'output standard (si può decidere come selettiva si vuole che sia, e potrebbe essere necessario modificare l'ortografia in base al paese e O / S) e la >&2 finale significa che i messaggi di errore superstiti (scritti sullo standard output) vanno per errore standard ancora una volta. Il reindirizzamento finale potrebbe essere considerato come optional presso il terminale, ma sarebbe una buona idea usarlo in uno script in modo che i messaggi di errore in caso di errore standard.

Ci sono infinite variazioni su questo tema, a seconda di cosa si vuole fare. Ciò funzionerà su qualsiasi variante di Unix con qualsiasi Bourne shell derivato (Bash, Korn, ...) e qualsiasi versione POSIX-compliant find .

Se si desidera adattarsi alla specifica versione di find avete sul vostro sistema, ci possono essere opzioni alternative disponibili. GNU find in particolare, ha una miriade di opzioni non disponibili in altre versioni -. Si veda la risposta attualmente accettato per una tale serie di opzioni

Usa:

find . ! -readable -prune -o -print

o più in generale

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

per evitare di "Autorizzazione negata"
E non sopprimere i messaggi (altro) di errore
e ottenere lo stato di uscita 0 ( "tutti i file vengono elaborati con successo")

Funziona con: find (findutils GNU) 4.4.2. Background:

Il test -readable corrisponde file leggibili. L'operatore ! restituisce true, quando la prova è falso. E ! -readable corrisponde directory non leggibile (e file).
L'azione -prune non discende nella directory.
! -readable -prune può essere tradotto in: se la directory non è leggibile, non scende in esso
Il test -readable tiene conto delle liste di controllo degli accessi e altri manufatti autorizzazioni che il test -perm ignora.

Si veda anche find (1) manpage per molti di più i dettagli.

Se si desidera avviare la ricerca dalla radice "/", probabilmente vedrete quarantina di uscita come:

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

E 'a causa del permesso. Per risolvere questo problema:

È possibile utilizzare il comando sudo: sudo find /. -name 'toBeSearched.file'. chiede super password dell'utente, quando inserire la password si vedrà portare ciò che si vuole veramente.
È possibile utilizzare reindirizzare l'output di errore standard da (Generalmente display / schermo) per un po 'di file e evitare di vedere i messaggi di errore sullo schermo! reindirizzare a un file speciale / dev / null:
```
find /. -name 'toBeSearched.file' 2>/dev/null
```
È possibile utilizzare reindirizzare l'output di errore standard da (Generalmente display / schermo) sullo standard output (Generalmente display / schermo), quindi il tubo con il comando grep con -v parametro "invertito" per non vedere le linee di uscita che ha 'autorizzazione negata' coppie di parole:
```
find /. -name 'toBeSearched.file' 2>&1 | grep -v 'Permission denied'
```

Ho dovuto usare:

find / -name expect 2>/dev/null

specificando il nome di quello che volevo trovare e poi raccontarla per reindirizzare tutti gli errori a / dev / null

si aspettano essere la posizione del programma si aspettano che stavo cercando.

Tubazioni stderr a /dev/null utilizzando 2> / dev / null

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

È inoltre possibile utilizzare il -perm e -prune predicati per evitare di scendere in directory illeggibili (vedi anche Come faccio a rimuovere "permesso negato" dichiarazioni tabulato dal programma find - Unix e Linux Stack scambio ):?

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

Errore di reindirizzamento standard. Per esempio, se si sta utilizzando bash su una macchina Unix, è possibile reindirizzare errore standard a / dev / null in questo modo:

find . 2>/dev/null >files_and_folders

Mentre gli approcci di cui sopra non affrontano il caso di Mac OS X, perché Mac Os X non supporta interruttore -readable questo è come si può evitare 'Autorizzazione negata' errori nell'output. Questo potrebbe aiutare qualcuno.

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

Se stai usando qualche altro comando con find, per esempio, per trovare la dimensione dei file di certo modello in un 2>/dev/null directory potrebbe funzionare come illustrato di seguito.

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

Ciò restituirà la dimensione totale dei file di un determinato modello. Si noti la 2>/dev/null alla fine del comando find.

Tali errori vengono stampati alla standard error (fd 2). Per filtrare fuori, semplicemente reindirizzare tutti gli errori a / dev / null:

find . 2>/dev/null > some_file

o prima aderire stderr e stdout e quindi grep quei errori specifici:

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

Risposta semplice:

find . > files_and_folders 2>&-

2>&- chiude (-) standard descrittore di file di errore (2) in modo che tutti i messaggi di errore vengono a tacere.

Exit sarà ancora 1 se gli errori di qualsiasi 'Permission denied' altrimenti essere stampati

risposta robusta per GNU `find`:

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

passare opzioni extra per find che -prune (prevenire scendere in), ma ancora -print qualsiasi directory ( -type d) che non lo fa ( \! ) hanno entrambi -readable e -executable per missioni, o ( -o ) -print qualsiasi altro file.

-readable e opzioni -executable sono estensioni GNU, non parte standard POSIX
Può ancora tornare 'Permission denied' sul file anomali / corrotti (ad esempio, vedere bug report interessano filesystem-container montato utilizzando lxcfs

risposta robusto che funziona con qualsiasi `find` POSIX-compatibile (GNU, OSX / BSD, ecc)

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

Usa un gasdotto di passare allo standard flusso di errore di grep , rimuovendo tutte le righe che contengono la stringa 'Permission denied'.

LC_ALL=C imposta la POSIX utilizzando un ambiente variabile, 3>&2 2>&1 1>&3 e 3>&2 2>&1 descrittori di file duplicati per il tubo del flusso standard di errore per grep, e usi [ $? = 1 ] [] per invertire il codice di errore restituito da grep per approssimare il comportamento originale di find.

Sarà anche filtrare eventuali errori 'Permission denied' a causa di reindirizzamento di uscita (ad esempio, se il file di esso files_and_folderssé non è scrivibile)

Per evitare di solo il permesso negato avvertimenti, di 'trovare per ignorare i file illeggibili da loro potatura dalla ricerca. Aggiungere un'espressione come un OR per il trovare, ad esempio

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

Questo dice soprattutto per (corrisponde un file illeggibile e prugna dall'elenco) o (corrisponde un nome come * .jbd e visualizzarlo [con ls]) . (Ricordate che per default le espressioni sono AND, insieme a meno di utilizzare -o.) È necessario i -ls nella seconda espressione oppure trovare possono aggiungere un'azione di default per mostrare entrambi i match, che si mostrerà anche tutti i file illeggibili .

Ma se siete alla ricerca di file reali sul vostro sistema, di solito non c'è motivo per guardare in / dev, che ha molti molti file, così si dovrebbe aggiungere un'espressione che esclude tale directory, come:

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

(file illeggibile partita e potare dalla lista) o (partita percorso / dev e potare dalla lista) o (file in partita come * .jbd e visualizzarla) .

utilizzo

sudo find / -name file.txt

E 'stupido (perché si elevare la ricerca) e non protetto, ma molto più breve di scrivere.

Nessuna delle risposte sopra funzionato per me. Qualunque cosa che trovo su internet si concentra su: nascondere gli errori. Nessuno gestisce correttamente l'/ uscita codice procedura di restituzione-code. Io uso comando find all'interno di script bash per individuare alcune directory e quindi ispezionare il loro contenuto. Valuto comando di trovare il successo con l'uscita del codice: un valore pari a zero opere, altrimenti fallisce

Il risposta fornita sopra di Michael Brux volte funziona. Ma ho una scenario in cui non riesce! Ho scoperto il problema e risolto da solo. Ho bisogno di potare i file quando:

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

Vedere la questione chiave è: E / O. Un buon suggerito sequenza di condizioni che ho letto è:

-type d ! -readable ! -executable -prune

Questo non funziona sempre. Ciò significa che una prugna viene attivato quando una partita è:

it is directory AND no read access AND no execute access

Questa sequenza di espressioni non riesce quando l'accesso viene concesso di leggere, ma non eseguire l'accesso è.

Dopo alcune prove mi sono reso conto di questo e ha cambiato la mia soluzione script di shell per:

nice find / home * / -maxdepth 5 -follow \
  \ (Tipo D -a ! \ (-Readable -a -executable \) \) -prune \
  -o \
  \ (Tipo D -a -readable -a -executable -a -name "$ {} m_find_name" \) -print

La chiave qui è quello di mettere il "non è vero" per un'espressione combinato:

has read access AND has execute access

In caso contrario, non ha pieno accesso, il che significa: potare esso. Questo si è rivelato a lavorare per me in uno scenario che le soluzioni proposte precedenti non riuscita.

Fornisco qui di seguito i dettagli tecnici per domande nella sezione commenti. Mi scuso se i dettagli sono eccessivi.

¿Perché utilizzando il comando bello? Ho avuto l'idea qui . Inizialmente ho pensato che sarebbe stato bello per ridurre le priorità del processo quando si cerca un intero file system. Mi sono reso conto che non ha senso per me, come il mio script è limitato a alcune directory. Ho ridotto -maxdepth a 3.
¿Perché una ricerca all'interno di / home * /? Questo non rilevante per questo thread. Installa tutte le applicazioni a mano tramite codice sorgente compilare con utenti non privilegiati (non root). Sono installati all'interno di "/ home". Posso avere più file binari e le versioni che vivono insieme. Ho bisogno di trovare tutte le directory, la verifica e il backup in modo master-slave. Posso avere più di un "/ home" (diversi dischi in esecuzione all'interno di un server dedicato).
¿Perché utilizzare -follow? Gli utenti potrebbero creare collegamenti simbolici a directory. E 'utilità dipende, ho bisogno di tenere traccia dei percorsi assoluti trovati.

È possibile utilizzare il comando grep-v invert-match

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

come questa:

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

Dovrebbe alla magia

- = Per MacOS = -

Crea un nuovo comando usando alias: è sufficiente aggiungere in ~ linea / .bash_profile:

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

e in una nuova finestra Terminale si può chiamare:

$ file=<filename or mask>; search

Ad esempio:

$ file = ecc; Ricerca

Se si utilizza CSH o TCSH, ecco una soluzione:

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

Se si desidera l'uscita al terminale:

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

Tuttavia, come la FAQ "csh-WhyNot" descrive, non si dovrebbe usare CSH.

È anche una soluzione semplice per mettere i risultati trovare in un file.

trova. -name 'NameOfSearchedFile' >> results.txt

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow