Wie kann ich alle "Zugriff verweigert" Nachrichten von "find" ausschließen?

Question

Ich muss alle Zugriff verweigert Nachrichten ausblenden von:

find . > files_and_folders

Ich experimentiere, wenn solche Nachrichten auftreten. Ich muss alle Ordner und Dateien sammeln, bei denen es nicht auftritt.

Ist es möglich, die Berechtigungsebenen auf die files_and_folders Datei umzuleiten?

Wie kann ich gleichzeitig die Fehler ausblenden?

Answer 1

Einfache Antwort:

find . > files_and_folders 2>&-

_2>&- schließt (-) den Standardfehler-Dateideskriptor (2), sodass alle Fehlermeldungen stummgeschaltet werden._

• Der Exit-Code wird immer noch 1 sein, wenn irgendwelche 'Zugriff verweigert' Fehler ausgegeben werden würden

Robuste Antwort für GNU find:

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

_Übergeben Sie zusätzliche Optionen an find das -prune (Verhindern des Abstiegs in) aber dennoch -print jedes Verzeichnis (-typed), das nicht (\!) sowohl Lese- als auch Ausführungsberechtigungen hat, oder (-o) -print jede andere Datei._

• -readable und -executable Optionen sind GNU-Erweiterungen und gehören nicht zum POSIX-Standard
• Kann weiterhin 'Zugriff verweigert' bei abnormen/beschädigten Dateien zurückgeben (z.B. siehe Fehlerbericht, der Container-mountierte Dateisysteme betrifft, die lxcfs < v2.0.5 verwenden)

Robuste Antwort, die mit jedem POSIX-kompatiblen find funktioniert (GNU, OSX/BSD, usw.)

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

_Verwenden Sie einen Pipe, um den Standardfehlerstrom an grep zu übergeben, und entfernen Sie alle Zeilen, die den String 'Permission denied' enthalten._

_LC_ALL=C setzt die POSIX-Lokale unter Verwendung einer Umgebungsvariable, 3>&2 2>&1 1>&3 und 3>&2 2>&1 duplizieren Dateideskriptoren, um den Standardfehlerstrom an grep zu leiten, und [ $? = 1 ] verwendet [] um den Fehlercode, der von grep zurückgegeben wird, umzukehren, um das ursprüngliche Verhalten von find zu approximieren._

• Filtert auch alle 'Zugriff verweigert' Fehler aufgrund von Ausgaberichtlinien (z.B. wenn die Datei files_and_folders selbst nicht beschreibbar ist)

Answer 2

Um die Warnungen für Berechtigungsverweigerungen zu vermeiden, teilen Sie find mit, dass es die nicht lesbaren Dateien ignorieren soll, indem Sie sie aus der Suche ausschließen. Fügen Sie einen Ausdruck als ODER zu Ihrem find-Befehl hinzu, zum Beispiel

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

Dies sagt größtenteils aus, dass (eine nicht lesbare Datei gefunden und aus der Liste ausgenommen wird) ODER (einen Namen wie *.jbd finden und anzeigen [mit ls]). (Denken Sie daran, dass die Ausdrücke standardmäßig UND-verknüpft sind, es sei denn, Sie verwenden -or.) Sie benötigen das -ls im zweiten Ausdruck, sonst könnte find eine Standardaktion hinzufügen, um eines der beiden Ergebnisse anzuzeigen, was auch alle nicht lesbaren Dateien anzeigen würde.

Aber wenn Sie echte Dateien auf Ihrem System suchen, gibt es normalerweise keinen Grund, in /dev zu suchen, da es viele Dateien enthält. Daher sollten Sie einen Ausdruck hinzufügen, der dieses Verzeichnis ausschließt, wie zum Beispiel:

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

Also (nicht lesbare Datei finden und aus der Liste ausnehmen) ODER (Pfad /dev finden und aus der Liste ausnehmen) ODER (Datei wie *.jbd finden und anzeigen).

Answer 3

Verwenden Sie dies einfach, um nach einer Datei in Ihrem System zu suchen.

find / -name DEIN_SUCHBEGRIFF 2>&1 | grep DEIN_SUCHBEGRIFF

Lassen Sie uns keine unnötige Überentwicklung betreiben, Sie möchten doch nur nach Ihrer Datei suchen, oder? Dann ist dies der Befehl, der Ihnen die Dateien auflistet, wenn sie in einem für Sie zugänglichen Bereich vorhanden sind.

Answer 4

Verwenden

sudo find / -name file.txt

Es ist dumm (weil du die Suche erhöhst) und unsicher, aber viel kürzer zu schreiben.

Answer 5

Keine der obigen Antworten hat für mich funktioniert. Alles, was ich im Internet finde, konzentriert sich darauf: Fehler ausblenden. Keiner behandelt den Prozessrückgabecode / Exit-Code richtig. Ich verwende den Befehl find in Bash-Skripten, um bestimmte Verzeichnisse zu lokalisieren und ihren Inhalt zu inspizieren. Ich bewerte den Erfolg des Befehls find anhand des Exit-Codes: ein Wert null funktioniert, ansonsten schlägt es fehl.

Die oben bereitgestellte Antwort von Michael Brux funktioniert manchmal. Aber in einem Szenario versagt sie! Ich habe das Problem entdeckt und selbst behoben. Ich muss Dateien ausschließen, wenn:

es sich um ein Verzeichnis handelt UND kein Lesezugriff vorhanden ist UND/ODER kein Ausführungszugriff vorhanden ist

Das Hauptproblem hier ist: UND/ODER. Eine gute vorgeschlagene Bedingungssequenz, die ich gelesen habe, ist:

-type d ! -readable ! -executable -prune

Dies funktioniert nicht immer. Das bedeutet, dass ein Ausschluss ausgelöst wird, wenn eine Übereinstimmung vorliegt:

es handelt sich um ein Verzeichnis UND kein Lesezugriff UND kein Ausführungszugriff

Diese Sequenz von Ausdrücken versagt, wenn der Lesezugriff gewährt wird, jedoch kein Ausführungszugriff vorhanden ist.

Nach einigen Tests habe ich das erkannt und meine Shell-Skriptlösung geändert in:

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

Der Schlüssel hier ist, das "nicht wahr" für einen kombinierten Ausdruck zu platzieren:

hat Lesezugriff UND hat Ausführungszugriff

Andernfalls hat es keinen vollen Zugriff, was bedeutet: es ausschließen. Dies hat sich für mich in einem Szenario bewährt, in dem vorherige vorgeschlagene Lösungen versagten.

Ich liefere unten technische Details für Fragen im Kommentarbereich. Es tut mir leid, wenn die Details übermäßig sind.

• Warum den Befehl nice verwenden? Ich habe die Idee hier bekommen. Zunächst dachte ich, es wäre angenehm, die Prozesspriorität zu reduzieren, wenn ich ein ganzes Dateisystem durchsuche. Ich habe festgestellt, dass es für mich keinen Sinn macht, da mein Skript auf wenige Verzeichnisse beschränkt ist. Ich habe -maxdepth auf 3 reduziert.
• Warum innerhalb von /home* suchen? Dies ist für diesen Thread nicht relevant. Ich installiere alle Anwendungen manuell durch das Kompilieren des Quellcodes mit nicht privilegierten Benutzern (nicht root). Sie sind innerhalb von "/home" installiert. Ich kann mehrere Binärdateien und Versionen zusammen installiert haben. Ich muss alle Verzeichnisse lokalisieren, inspizieren und auf Master-Slave-Weise sichern. Ich kann mehr als ein "/home" haben (mehrere Laufwerke innerhalb eines dedizierten Servers).
• Warum -follow verwenden? Benutzer könnten symbolische Links zu Verzeichnissen erstellen. Der Nutzen hängt davon ab, ich muss die absoluten Pfade der gefundenen Pfade festhalten.