Suchen Sie mit dem Befehl find nach ausführbaren Dateien

Welche Art von Parameter / Flag kann ich mit dem Unix- findBefehl verwenden, um ausführbare Dateien zu durchsuchen?

Auf GNU-Versionen von find können Sie Folgendes verwenden -executable:

find . -type f -executable -print

Für BSD - Versionen finden, können Sie -permmit +und ein Oktal - Maske:

find . -type f -perm +111 -print

In diesem Zusammenhang bedeutet "+" "jedes dieser Bits ist gesetzt" und 111 sind die Ausführungsbits.

Beachten Sie, dass dies nicht mit dem -executablePrädikat in GNU find identisch ist . Insbesondere wird -executablegetestet, ob die Datei vom aktuellen Benutzer ausgeführt werden kann, während -perm +111nur getestet wird, ob Ausführungsberechtigungen festgelegt sind.

Ältere Versionen von GNU find unterstützen ebenfalls die -perm +111Syntax, aber ab 4.5.12 wird diese Syntax nicht mehr unterstützt. Stattdessen können Sie -perm /111dieses Verhalten verwenden , um es zu erhalten.

^{Tipp des Hutes an @ gniourf_gniourf, um ein grundlegendes Missverständnis auszuräumen .}

Diese Antwort versucht, einen Überblick über die vorhandenen Antworten zu geben und ihre Feinheiten und relativen Vorzüge zu diskutieren sowie Hintergrundinformationen bereitzustellen , insbesondere in Bezug auf die Portabilität .

Das Suchen von Dateien, die ausführbar sind, kann sich auf zwei unterschiedliche Anwendungsfälle beziehen :

• user-centric : Finden Sie Dateien, die ausführbare Datei vom aktuellen Benutzer .
• dateizentriert : Suchen Sie nach Dateien, für die (ein oder mehrere) ausführbare Berechtigungsbits gesetzt sind .

Beachten Sie, dass in beide es Szenario kann sinnvoll sein zu verwendenfind -L ... , anstatt nur find ...zu , um auch zu finden Symlinks zu ausführbaren Dateien .

Beachten Sie, dass der einfachste dateizentrierte Fall - das Suchen nach ausführbaren Dateien mit dem für ALLE drei Sicherheitsprinzipale (Benutzer, Gruppe, andere) gesetzten ausführbaren Berechtigungsbit - normalerweise , aber nicht unbedingt die gleichen Ergebnisse liefert wie das benutzerzentrierte Szenario - und das ist es wichtig, um den Unterschied zu verstehen.

Benutzerzentriert ( -executable)

• Die akzeptierte Antwort empfiehlt lobenswerterweise -executable, WENN GNU find verfügbar ist.

  • GNU findwird mit den meisten Linux-Distributionen geliefert
    • Im Gegensatz dazu verfügen BSD-basierte Plattformen, einschließlich macOS, über BSD find, das weniger leistungsfähig ist.
  • Entspricht je nach Szenario -executablenur den Dateien, die der aktuelle Benutzer ausführen kann (es gibt Randfälle. ^[1] ).

• Die BSD find - Alternative durch die akzeptierte Antwort angeboten ( -perm +111) beantwortet eine andere , Datei -centric Frage (wie die Antwort selbst erklärt).

  • Es ist unmöglich-perm , nur die benutzerzentrierte Frage zu beantworten , da die Benutzer- und Gruppenidentität der Datei mit der des aktuellen Benutzers in Beziehung gesetzt werden muss , während nur die Berechtigungen der Datei getestet werden können . Wenn nur POSIX- Funktionen verwendet werden , kann die Frage nicht ohne externe Dienstprogramme beantwortet werden.-perm
find

  • So das Beste -permtun kann (selbst) ist eine Annäherung an -executable. Vielleicht eine engere Annäherung als es -perm +111ist-perm -111 , um Dateien zu finden, bei denen das ausführbare Bit für ALLE Sicherheitsprinzipale (Benutzer, Gruppe, andere) gesetzt ist - dies scheint mir das typische reale Szenario zu sein. Als Bonus ist es auch POSIX-kompatibel ( find -Lzum Einschließen von Symlinks, siehe unten für eine Erklärung):

    find . -type f -perm -111  # or: find . -type f -perm -a=x

• Die Antwort von gniourf_gniourf bietet ein echtes, portables Äquivalent zur-executable Verwendung-exec test -x {} \;, wenn auch auf Kosten der Leistung .

  • Die Kombination -exec test -x {} \; mit -perm +111(dh Dateien mit mindestens einem ausführbaren Bit-Satz) kann dazu beitragen, dass die Leistung execnicht für jede Datei aufgerufen werden muss (im Folgenden wird das POSIX-kompatible Äquivalent von BSD find -perm +111/ GNU find verwendet -perm /111; eine Erklärung finden Sie weiter unten). ::

    find . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \) -exec test -x {} \; -print

Dateizentrisch ( -perm)

• Zur Beantwortung Datei -centric Fragen , es ist ausreichend , um die POSIX-konform zu verwenden -permprimären (bekannt als ein Test in GNU find Terminologie).
  • -permMit dieser Option können Sie alle Dateiberechtigungen testen , nicht nur die Ausführbarkeit.
  • Berechtigungen werden entweder als oktaler oder als symbolischer Modus angegeben . Oktalmodi sind Oktalzahlen (z. B. 111), während symbolische Modi Zeichenfolgen (z a=x. B. ) sind.
  • Symbolische Modi identifizieren die Sicherheitsprinzipale als u(Benutzer), g(Gruppe) und o(andere) oder abeziehen sich auf alle drei. Berechtigungen werden wie folgt ausgedrückt xfür ausführbare, zum Beispiel, und übertrugen an Principals Operatoren =, +und -; Eine vollständige Beschreibung, einschließlich der Oktalmodi, finden Sie in der POSIX-Spezifikation des chmodDienstprogramms .
  • Im Zusammenhang mit find:
    • Das Präfixieren eines Modus mit- (z. B. -ug=x) bedeutet: Übereinstimmungsdateien mit allen angegebenen Berechtigungen (übereinstimmende Dateien können jedoch zusätzliche Berechtigungen haben).
    • Mit NO Präfix (zB 755) bedeutet: Match - Dateien , die diese haben volle, genaue Menge von Berechtigungen.
    • Vorsichtsmaßnahme : Sowohl die GNU-Suche als auch die BSD-Suche implementieren ein zusätzliches, nicht standardmäßiges Präfix mit der Logik , dass die angegebenen Berechtigungsbits gesetzt sind, dies jedoch mit inkompatibler Syntax :
      • BSD finden: +
      • GNU finden: / ^[2]
    • Daher vermeidet diese Erweiterungen, wenn Ihr Code sein muss tragbar .
• Die folgenden Beispiele zeigen tragbare Antworten auf verschiedene dateizentrierte Fragen.

Beispiele für dateizentrierte Befehle

Hinweis:

• Die folgenden Beispiele sind POSIX-kompatibel , dh sie sollten in jeder POSIX-kompatiblen Implementierung funktionieren, einschließlich GNU-Suche und BSD-Suche. Dies erfordert insbesondere:
  • NICHT mit nicht standardmäßigen Moduspräfixen +oder /.
  • Verwenden der POSIX-Formulare der Primäroperationen für logische Operatoren :
    • !für NOT (GNU find und BSD find erlauben ebenfalls -not); Beachten Sie, dass dies \!in den Beispielen verwendet wird, um !vor Erweiterungen des Shell-Verlaufs zu schützen
    • -afür AND (GNU find und BSD find erlauben auch -and)
    • -ofür OR (GNU find und BSD find erlauben auch -or)
• Die Beispiele verwenden symbolische Modi, da sie leichter zu lesen und zu merken sind.
  • Mit Mode - Präfix -, die =und +können die Betreiber untereinander ausgetauscht werden (zB -u=xentspricht -u+x- es sei denn , Sie gelten -xspäter, aber es gibt keinen Punkt in tun das).
  • Verwenden Sie ,diese Option , um Teilmodi zu verbinden. UND-Logik ist impliziert; Dies -u=x,g=xbedeutet beispielsweise, dass sowohl der Benutzer als auch das ausführbare Gruppenbit gesetzt werden müssen.
  • Modi können selbst keine negative Übereinstimmung im Sinne von "Übereinstimmung nur, wenn dieses Bit NICHT gesetzt ist" ausdrücken. Sie müssen einen separaten -permAusdruck mit dem NOT-Primärcode verwenden !.
• Beachten Sie, dass die Primärdaten von find (wie -printoder oder -permauch als Aktionen und Tests in GNU find bezeichnet) implizit mit -a(logisches UND) verknüpft sind und dass -ound möglicherweise Klammern (als \(und \)für die Shell maskiert) erforderlich sind, um die ODER-Logik zu implementieren.
• find -L ...statt nur find ...wird verwendet, um auch Symlinks mit ausführbaren Dateien abzugleichen
  • -Lweist find an, die Ziele von Symlinks anstelle der Symlinks selbst zu bewerten ; also ohne -L, -type fwürde ignorieren ganz Symlinks.

# Match files that have ALL executable bits set - for ALL 3 security
# principals (u (user), g (group), o (others)) and are therefore executable
# by *anyone*.
# This is the typical case, and applies to executables in _system_ locations
# (e.g., /bin) and user-installed executables in _shared_ locations
# (e.g., /usr/local/bin), for instance. 
find -L . -type f -perm -a=x  # -a=x is the same as -ugo=x

# The POSIX-compliant equivalent of `-perm +111` from the accepted answer:
# Match files that have ANY executable bit set.
# Note the need to group the permission tests using parentheses.
find -L . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \)

# A somewhat contrived example to demonstrate the use of a multi-principial
# mode (comma-separated clauses) and negation:
# Match files that have _both_ the user and group executable bit set, while
# also _not_ having the other executable bit set.
find -L . -type f -perm -u=x,g=x  \! -perm -o=x

^{[1] Beschreibung von -executableab man findGNU-Fund 4.4.2:}

Entspricht ausführbaren Dateien und durchsuchbaren Verzeichnissen (im Sinne der Auflösung von Dateinamen). Dies berücksichtigt Zugriffssteuerungslisten und andere Berechtigungsartefakte, die vom -perm-Test ignoriert werden. Dieser Test verwendet den Systemaufruf access (2) und kann daher von NFS-Servern getäuscht werden, die UID-Mapping (oder Root-Squashing) durchführen, da viele Systeme den Zugriff (2) im Kernel des Clients implementieren und daher nicht verwenden können die auf dem Server gespeicherten UID-Zuordnungsinformationen. Da dieser Test nur auf dem Ergebnis des Systemaufrufs access (2) basiert, kann nicht garantiert werden, dass eine Datei, für die dieser Test erfolgreich ist, tatsächlich ausgeführt werden kann.

^{[2] GNU-Find-Versionen, die älter als 4.5.12 sind, erlaubten ebenfalls ein Präfix +, das jedoch zuerst veraltet und schließlich entfernt wurde, da die Kombination +mit symbolischen Modi wahrscheinlich zu unerwarteten Ergebnissen führt, da sie als exakte Berechtigungsmaske interpretiert werden . Wenn Sie (a) laufen auf einer Version vor 4.5.12 und (b) sich beschränken Oktal nur Modi, Sie könnten mit der Verwendung weg +mit beiden GNU finden und BSD finden, aber es ist keine gute Idee.}

Um eine andere Möglichkeit zu haben ¹ , die Dateien zu finden, die vom aktuellen Benutzer ausgeführt werden können:

find . -type f -exec test -x {} \; -print

(Der /usr/bin/testTestbefehl hier ist der in PATH gefundene, sehr wahrscheinlich nicht der eingebaute).

¹ Verwenden Sie diese Option nur, wenn die -executableFlagge von findnicht verfügbar ist! Dies unterscheidet sich geringfügig von der -perm +111Lösung.

Sie können das -executableTestflag verwenden:

-executable
              Matches files which are executable  and  directories  which  are
              searchable  (in  a file name resolution sense).

Das hat bei mir funktioniert und ich dachte daran zu teilen ...

find ./ -type f -name "*" -not -name "*.o" -exec sh -c '
    case "$(head -n 1 "$1")" in
      ?ELF*) exit 0;;
      MZ*) exit 0;;
      #!*/ocamlrun*)exit0;;
    esac
exit 1
' sh {} \; -print

find . -executable -type f

garantiert nicht wirklich, dass die Datei ausführbar ist, sondern findet Dateien mit gesetztem Ausführungsbit. Wenn Sie tun

chmod a+x image.jpg

Der obige Fund wird denken, dass image.jpg eine ausführbare Datei ist, selbst wenn es sich wirklich um ein JPEG-Image handelt, bei dem das Ausführungsbit gesetzt ist.

Im Allgemeinen arbeite ich damit um das Problem herum:

find . -type f -executable -exec file {} \; | grep -wE "executable|shared object|ELF|script|a\.out|ASCII text"

Wenn Sie möchten, dass der Fund tatsächlich Dome-Informationen zu ausführbaren Dateien druckt, können Sie Folgendes tun:

find . -type f -executable -printf "%i.%D %s %m %U %G %C@ %p" 2>/dev/null |while read LINE
do
  NAME=$(awk '{print $NF}' <<< $LINE)
  file -b $NAME |grep -qEw "executable|shared object|ELF|script|a\.out|ASCII text" && echo $LINE
done

Im obigen Beispiel befindet sich der vollständige Pfadname der Datei im letzten Feld und muss angeben, wo Sie mit awk "NAME = $ (awk '{print $ NF}' <<< $ LINE)" suchen, wenn sich der Dateiname an einer anderen Stelle befand Die Suchausgabezeichenfolge, die Sie benötigen, um "NF" durch die richtige numerische Position zu ersetzen. Wenn Ihr Trennzeichen kein Leerzeichen ist, müssen Sie awk auch mitteilen, was Ihr Trennzeichen ist.

Es ist so lächerlich, dass dies nicht ganz einfach ist ... geschweige denn so gut wie unmöglich . Hände hoch, ich verlasse mich auf Apple / Spotlight ...

mdfind 'kMDItemContentType=public.unix-executable'

Zumindest funktioniert es!

Die einfache Antwort wäre: "Ihre ausführbaren Dateien befinden sich in den Verzeichnissen, die in Ihrer PATH-Variablen enthalten sind", aber das würde Ihre ausführbaren Dateien nicht wirklich finden und könnte sowieso viele ausführbare Dateien übersehen.

Ich weiß nicht viel über Mac, aber ich denke, dass "mdfind 'kMDItemContentType = public.unix-ausführbare Datei" Dinge wie interpretierte Skripte vermissen könnte

Wenn es für Sie in Ordnung ist, Dateien mit gesetzten ausführbaren Bits zu finden (unabhängig davon, ob sie tatsächlich ausführbar sind), ist dies in Ordnung

find . -type f -perm +111 -print

Wenn dies unterstützt wird, wird mit der Option "-executable" ein weiterer Filter erstellt, der sich mit acl und anderen Berechtigungsartefakten befasst, unterscheidet sich jedoch technisch nicht wesentlich von "-pemr +111".

Vielleicht wird find in Zukunft "-magic" unterstützen und Sie können explizit nach Dateien mit einer bestimmten magischen ID suchen ... aber dann müssten Sie angeben, um alle magischen IDs der ausführbaren Formate zu optimieren.

Mir ist kein technisch korrekter einfacher Ausweg unter Unix bekannt.

Also , wenn Sie tatsächlich ausführbare Dateitypen finden möchten (zB Skripte, ELF - Binaries etc .. etc ..) nicht nur Dateien mit der Ausführung Erlaubnis dann möchten Sie wahrscheinlich etwas mehr wie dies tun (wo das aktuelle Verzeichnis. Mit was auch immer ersetzt werden Verzeichnis, das Sie wollen):

 gfind . -type f -exec bash -c '[[ $(file -b "'{}'") == *" executable "* ]] ' \; -print

Oder für diejenigen unter Ihnen, die keine Macports verwenden (Linux-Benutzer) oder auf andere Weise gnu find installiert haben, wie Sie es möchten:

 find . -type f -exec bash -c '[[ $(file -b "'{}'") == *" executable "* ]] ' \; -print

Wenn Sie unter OS X arbeiten, ist ein kleines Dienstprogramm namens is_exec enthalten, das diesen kleinen Test für Sie bündelt, sodass Sie die Befehlszeile verkürzen können, wenn Sie ihn finden. Diese Methode ist jedoch flexibler, da Sie den == -Test leicht durch den = ~ -Test ersetzen und damit nach komplexeren Eigenschaften wie ausführbaren Nur-Text-Dateien oder anderen Informationen suchen können, die Ihr Dateibefehl zurückgibt.

Die genauen Regeln für das Zitieren hier sind ziemlich undurchsichtig, so dass ich es am Ende nur durch Ausprobieren ausarbeite, aber ich würde gerne die richtige Erklärung hören.

Ich hatte das gleiche Problem und die Antwort war im Quellmenü des Menüs : das zu diesem Zweck erstellte Dienstprogramm stest. Sie können die Dateien 'stest.c' und 'arg.h' kompilieren und es sollte funktionieren. Es gibt eine Manpage für die Verwendung, die ich der Einfachheit halber dort abgelegt habe:

STEST(1)         General Commands Manual         STEST(1)

NAME
       stest - filter a list of files by properties

SYNOPSIS
       stest  [-abcdefghlpqrsuwx]  [-n  file]  [-o  file]
       [file...]

DESCRIPTION
       stest takes a list of files  and  filters  by  the
       files'  properties,  analogous  to test(1).  Files
       which pass all tests are printed to stdout. If  no
       files are given, stest reads files from stdin.

OPTIONS
       -a     Test hidden files.

       -b     Test that files are block specials.

       -c     Test that files are character specials.

       -d     Test that files are directories.

       -e     Test that files exist.

       -f     Test that files are regular files.

       -g     Test  that  files  have  their set-group-ID
              flag set.

       -h     Test that files are symbolic links.

       -l     Test the contents of a directory  given  as
              an argument.

       -n file
              Test that files are newer than file.

       -o file
              Test that files are older than file.

       -p     Test that files are named pipes.

       -q     No  files are printed, only the exit status
              is returned.

       -r     Test that files are readable.

       -s     Test that files are not empty.

       -u     Test that files have their set-user-ID flag
              set.

       -v     Invert  the  sense  of  tests, only failing
              files pass.

       -w     Test that files are writable.

       -x     Test that files are executable.

EXIT STATUS
       0      At least one file passed all tests.

       1      No files passed all tests.

       2      An error occurred.

SEE ALSO
       dmenu(1), test(1)

                        dmenu-4.6                STEST(1)