Rechercher des fichiers exécutables à l'aide de la commande find

Quel type de paramètre / indicateur puis-je utiliser avec la findcommande Unix pour rechercher des exécutables?

Sur les versions GNU de find, vous pouvez utiliser -executable:

find . -type f -executable -print

Pour les versions BSD de find, vous pouvez utiliser -permavec +et un masque octal:

find . -type f -perm +111 -print

Dans ce contexte, "+" signifie "n'importe lequel de ces bits est mis à 1" et 111 sont les bits d'exécution.

Notez que ce n'est pas identique au -executableprédicat dans GNU find. En particulier, -executableteste que le fichier peut être exécuté par l'utilisateur actuel, tout en -perm +111testant simplement si des autorisations d'exécution sont définies.

Les anciennes versions de GNU find prennent également en charge la -perm +111syntaxe, mais à partir de 4.5.12, cette syntaxe n'est plus prise en charge. Au lieu de cela, vous pouvez utiliser -perm /111pour obtenir ce comportement.

^{Astuce du chapeau à @ gniourf_gniourf pour éclaircir une idée fausse fondamentale.}

Cette réponse tente de donner un aperçu des réponses existantes et de discuter de leurs subtilités et de leurs mérites relatifs ainsi que de fournir des informations de base , en particulier en ce qui concerne la portabilité .

La recherche de fichiers exécutables peut faire référence à deux cas d'utilisation distincts :

• centré sur l'utilisateur : recherchez les fichiers exécutables par l'utilisateur actuel .
• fichier-centrique : trouver les fichiers qui ont (un ou plusieurs) bits d'autorisation exécutable ensemble .

Notez que dans les deux scénarios, il peut être judicieux d' utiliserfind -L ... au lieu de juste find ...pour trouver également des liens symboliques vers des exécutables .

Notez que le cas le plus simple centré sur les fichiers - rechercher des exécutables avec le bit d'autorisations exécutable défini pour TOUS les trois principaux de sécurité (utilisateur, groupe, autre) - produira généralement , mais pas nécessairement, les mêmes résultats que le scénario centré sur l'utilisateur - et c'est important de comprendre la différence.

Centré sur l'utilisateur ( -executable)

• le réponse acceptée recommande vivement -executable, IF GNU find est disponible.

  • GNU findest fourni avec la plupart des distributions Linux
    • En revanche, les plates-formes basées sur BSD, y compris macOS, sont livrées avec BSD find, qui est moins puissant.
  • Comme le scénario l'exige, -executablene fait correspondre que les fichiers utilisateur actuel peut exécuter (il existe des cas extrêmes. ^[1] ).

• L' alternative BSD find offerte par la réponse acceptée ( -perm +111) répond à une autre , centrée sur le fichier (comme l'indique la réponse elle-même).

  • Il est impossible d' utiliser uniquement -permpour répondre à la question centrée sur l' utilisateur , car il est nécessaire de relier l' identité de l'utilisateur et du groupe du fichier à l' utilisateur actuel , alors que -permvous ne pouvez tester que le fichier. autorisations .
    En utilisant uniquement les findfonctionnalités POSIX , il est impossible de répondre à la question sans impliquer des utilitaires externes.

  • Ainsi, le mieux que l' -permon puisse faire (par lui-même) est une approximation de -executable. Peut-être une approximation plus proche que ne l' -perm +111est-perm -111 , afin de trouver des fichiers dont le bit exécutable est défini pour TOUS les principaux de sécurité (utilisateur, groupe, autre) - cela me semble être le scénario typique du monde réel. En prime, il est également compatible POSIX (utilisez find -Lpour inclure des liens symboliques, voir plus loin ci-dessous pour une explication):

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

• La réponse de gniourf_gniourf fournit un véritable équivalent portable de l'-executable utilisation-exec test -x {} \;, mais au détriment des performances .

  • La combinaison -exec test -x {} \; avec -perm +111(c'est-à-dire des fichiers avec au moins un ensemble de bits exécutables) peut améliorer les performances dans la mesure où il execn'est pas nécessaire d'appeler pour chaque fichier (ce qui suit utilise l'équivalent compatible POSIX de BSD find -perm +111/ GNU find-perm /111 ; voir plus loin ci-dessous pour une explication) :

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

Centré sur les fichiers ( -perm)

• Pour répondre fichiers des questions -centric , il est suffisant d'utiliser le conforme aux spécifications POSIX-perm primaire (appelé essai dans la terminologie de trouver GNU).
  • -permvous permet de tester toutes les autorisations de fichier, pas seulement l'exécutabilité.
  • Les autorisations sont spécifiées en mode octal ou symbolique . Les modes octaux sont des nombres octaux (par exemple, 111), tandis que les modes symboliques sont des chaînes (par exemple, a=x).
  • Les modes symboliques identifient les principaux de sécurité comme u(utilisateur), g(groupe) et o(autre), ou apour faire référence aux trois. Les autorisations sont exprimées comme xpour l'exécutable, par exemple, et attribuées aux principaux à l'aide d'opérateurs =, +et -; pour une discussion complète, y compris des modes octaux, voir la spécification POSIX pour lechmod utilitaire .
  • Dans le contexte de find :
    • Préfixer un mode avec- (par exemple, -ug=x) signifie: faire correspondre les fichiers qui ont toutes les autorisations spécifiées (mais les fichiers correspondants peuvent avoir des autorisations supplémentaires).
    • N'ayant AUCUN préfixe (par exemple 755) signifie: faire correspondre les fichiers qui ont ceci complet et exact d'autorisations.
    • Avertissement : GNU find et BSD find implémentent tous deux un préfixe non standard supplémentaire avec une logique de jeu de bits d'autorisations spécifiées , mais faites-le avec une syntaxe incompatible :
      • BSD trouver: +
      • Recherche GNU: / ^[2]
    • Par conséquent, évitez ces extensions, si votre code doit être portable .
• Les exemples ci-dessous présentent des réponses portables à diverses questions centrées sur les fichiers.

Exemples de commandes centrées sur les fichiers

Remarque:

• Les exemples suivants sont compatibles POSIX , ce qui signifie qu'ils devraient fonctionner dans n'importe quelle implémentation compatible POSIX, y compris GNU find et BSD find; spécifiquement, cela nécessite:
  • N'utilisez PAS de préfixes de mode non standard +ou /.
  • Utilisation des formes POSIX des primaires d'opérateurs logiques :
    • !pour NOT (GNU find et BSD find autorisent également -not); notez qu'il \!est utilisé dans les exemples pour se protéger !des extensions d'historique du shell
    • -apour AND (GNU find et BSD find autorisent également -and)
    • -opour OR (GNU find et BSD find autorisent également -or)
• Les exemples utilisent des modes symboliques , car ils sont plus faciles à lire et à mémoriser.
  • Avec le préfixe de mode -, les opérateurs =et +peuvent être utilisés de manière interchangeable (par exemple, -u=xéquivaut à -u+x- sauf si vous appliquez -xplus tard, mais cela ne sert à rien).
  • Utilisez ,pour rejoindre les modes partiels; ET la logique est implicite; par exemple, cela -u=x,g=xsignifie que l'utilisateur et le bit exécutable de groupe doivent être définis.
  • Les modes ne peuvent pas eux-mêmes exprimer une correspondance négative dans le sens de "correspondance uniquement si ce bit n'est PAS activé"; vous devez utiliser une distincte -permexpression avec NOT primaire, !.
• Notez que les primaires de find (telles que -print, ou -perm; également connues sous le nom d' actions et de tests dans GNU find) sont implicitement jointes avec -a(AND logique), et que -o, éventuellement entre parenthèses (échappées comme \(et\) pour le shell) sont nécessaires pour implémenter la logique OR.
• find -L ...au lieu de juste find ...est utilisé afin de faire correspondre également les liens symboliques à exécutables
  • -Lindique à find d'évaluer les cibles des liens symboliques au lieu des liens symboliques eux-mêmes; par conséquent, sans -L, -type fignorerait complètement les liens symboliques.

# 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] Description de à -executablepartir man findde GNU find 4.4.2:}

Correspond aux fichiers exécutables et aux répertoires pouvant faire l'objet d'une recherche (dans un sens de résolution de nom de fichier). Cela prend en compte les listes de contrôle d'accès et d'autres artefacts d'autorisations que le test -perm ignore. Ce test utilise l'appel système access (2), et peut donc être trompé par les serveurs NFS qui effectuent un mappage UID (ou écrasement de racine), car de nombreux systèmes implémentent access (2) dans le noyau du client et ne peuvent donc pas utiliser les informations de mappage UID conservées sur le serveur. Etant donné que ce test est basé uniquement sur le résultat de l'appel système access (2), il n'y a aucune garantie qu'un fichier pour lequel ce test réussit puisse réellement être exécuté.

^{[2] Les versions de GNU find antérieures à 4.5.12 autorisaient également le préfixe +, mais cela a d'abord été déconseillé et finalement supprimé, car la combinaison +avec des modes symboliques donne probablement des résultats inattendus car elle est interprétée comme un masque d'autorisations exact . Si vous (a) exécutez sur une version antérieure à la 4.5.12 et (b) vous vous limitez aux modes octaux uniquement, vous pourriez vous en sortir en utilisant +à la fois GNU find et BSD find, mais ce n'est pas une bonne idée.}

Pour avoir une autre possibilité ¹ de trouver les fichiers exécutables par l'utilisateur courant:

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

(la commande de test ici est celle trouvée dans PATH, très probablement /usr/bin/test, pas celle intégrée).

¹ N'utilisez ceci que si le -executabledrapeau de findn'est pas disponible! c'est subtilement différent de la -perm +111solution.

Vous pouvez utiliser l' -executableindicateur de test:

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

Cela a fonctionné pour moi et j'ai pensé à partager ...

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

ne garantit pas vraiment que le fichier est exécutable, il trouvera les fichiers avec le bit d'exécution défini. Si tu fais

chmod a+x image.jpg

la recherche ci-dessus pensera que image.jpg est un exécutable même s'il s'agit vraiment d'une image jpeg avec le bit d'exécution défini.

Je travaille généralement autour du problème avec ceci:

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

Si vous voulez que la recherche imprime réellement les informations du dôme sur les fichiers exécutables, vous pouvez faire quelque chose comme ceci:

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

Dans l'exemple ci-dessus, le chemin complet du fichier se trouve dans le dernier champ et doit refléter l'endroit où vous le recherchez avec awk "NAME = $ (awk '{print $ NF}' <<< $ LINE)" si le nom du fichier était ailleurs dans la chaîne de sortie de recherche dont vous avez besoin pour remplacer "NF" par la position numérique correcte. Si votre séparateur n'est pas un espace, vous devez également indiquer à awk quel est votre séparateur.

C'est tellement ridicule que ce n'est pas super facile ... encore moins presque impossible . Les mains en l'air, je m'en remets à Apple / Spotlight ...

mdfind 'kMDItemContentType=public.unix-executable'

Au moins ça marche!

Eh bien, la réponse simple serait: "vos fichiers exécutables sont dans les répertoires contenus dans votre variable PATH" mais cela ne trouverait pas vraiment vos exécutables et pourrait de toute façon manquer beaucoup d'exécutables.

Je ne sais pas grand-chose sur mac mais je pense que "mdfind 'kMDItemContentType = public.unix-executable'" pourrait manquer des éléments comme des scripts interprétés

Si vous pouvez trouver des fichiers avec les bits exécutables définis (qu'ils soient ou non exécutables), alors c'est bien de le faire

find . -type f -perm +111 -print

là où elle est prise en charge, l'option "-executable" créera un filtre supplémentaire regardant acl et d'autres artefacts de permission mais n'est techniquement pas très différente de "-pemr +111".

Peut-être qu'à l'avenir, find supportera "-magic" et vous permettra de rechercher explicitement des fichiers avec un identifiant magique spécifique ... mais alors vous devrez spécifier pour affiner tous les formats exécutables id magique.

Je ne connais pas de solution facile techniquement correcte sous Unix.

Donc, si vous voulez réellement trouver des types de fichiers exécutables (par exemple des scripts, des binaires ELF, etc.) pas simplement des fichiers avec l' autorisation d' exécution, vous voudrez probablement faire quelque chose de plus comme ça (où le répertoire courant peut être remplacé par n'importe quoi répertoire souhaité):

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

Ou pour ceux d'entre vous qui n'utilisent pas macports (utilisateurs Linux) ou qui ont installé gnu find comme find que vous voulez:

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

Cependant, si vous êtes sur OS X, il est livré avec un petit utilitaire caché quelque part appelé is_exec qui regroupe essentiellement ce petit test pour vous afin que vous puissiez raccourcir la ligne de commande si vous le trouvez. Mais cette méthode est plus flexible car vous pouvez facilement remplacer le test == par le test = ~ et l'utiliser pour rechercher des propriétés plus complexes telles que des fichiers texte exécutables ou toute autre information renvoyée par la commande de fichier.

Les règles exactes de citation ici sont assez opaques, donc je finis simplement par les résoudre par essais et erreurs, mais j'aimerais entendre la bonne explication.

J'ai eu le même problème, et la réponse était dans le code source de dmenu : l'utilitaire stest fait à cet effet. Vous pouvez compiler les fichiers 'stest.c' et 'arg.h' et cela devrait fonctionner. Il y a une page de manuel pour l'utilisation, que je mets là pour plus de commodité:

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)