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


113

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


tapez «homme trouver». Je pense que «-executable» est l'option que vous voulez.
sje397

3
find -executable... mais cela ne garantit pas que tous les fichiers répertoriés s'exécuteraient réellement
William

1
Toutes les implémentations de ne findsont pas créées égales. L'option recommandée par @ sje397 et @William peut ne pas être disponible. Il est préférable d'utiliser la solution acceptée ci-dessous.
LS


Je n'aime pas toutes les propositions ci-dessous qui sont basées sur les autorisations de fichier. Argumentation: pour mon système d'exploitation GNU (Ubuntu), il est possible de définir l'indicateur "x" (exécutable) pour un fichier texte ASCII par exemple. Aucune imitation n'a empêché cette opération de se terminer correctement. Il suffit d'une petite erreur / bogue pour que plusieurs fichiers non intentionnels obtiennent le drapeau x attribué. Par conséquent, les solutions de gniourf_gniourf sont mes préférées. Il a cependant cet inconvénient que pour les exécutables compilés de manière croisée, il faut un émulateur ou un périphérique cible.
Na13-c

Réponses:


173

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.


Erreur find: invalid mode ‘+111’sur findutils 4.5.11 4.fc20.
sourcejedi

1
@sourcejedi Merci. Je ne parlais en fait que des versions non GNU de find (BSD, en particulier), mais les anciennes versions de GNU find supportaient également cette syntaxe. Dans les versions plus récentes, vous devrez utiliser à la /place de +. Voir la réponse mise à jour pour plus de détails.
Laurence Gonsalves

En effet, j'ai mal lu votre réponse. Désolé d'avoir compliqué les choses :).
sourcejedi

Si les liens symboliques vers des fichiers exécutables doivent également être trouvés, inclure l' -Loption de : find -L ....
mklement0

Il m'a fallu un certain temps pour comprendre les implications de "pas identique au prédicat -executable" et "juste des tests si des autorisations d'exécution sont définies": cela signifie que cela -perm +111peut produire des faux positifs , c'est-à-dire des fichiers que l'utilisateur actuel ne peut pas exécuter. Il n'y a aucun moyen d'émuler -executableen testant uniquement les autorisations, car ce qui est nécessaire est de relier l' identité de l'utilisateur et du groupe du fichier à l' utilisateur actuel .
mklement0

35

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.


2
La réponse SO la plus complète jamais vue? ;)
andynormancx

@andynormancx :) Eh bien, en termes de nombre de puces, je peux offrir ce candidat .
mklement0

11

Pour avoir une autre possibilité 1 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).


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


2
Cela fonctionne, mais c'est assez lent. En outre, selon le shell, vous devrez peut-être encapsuler ou échapper l'espace réservé au nom de fichier, comme '{}'ou \{\}.
Ionoclast Brigham

1
@ mklement0 cela ne trouvera pas les commandes qui sont exécutables par moi comme le -executablefait ou comme ma commande le fait.
gniourf_gniourf

1
Merci, @gniourf_gniourf - J'avais vraiment quelques idées fausses là-bas. Je réimprime votre autre commentaire ici, car je suis au moins pour l'instant en train de supprimer ma réponse (peut-être pour être ressuscité, SI il y a quelque chose de récupérable): " find . -type f -perm -u=xest pas l'équivalent de -executable: -executablecorrespond à tous les fichiers que l'utilisateur peut exécuter, et ceux-ci incluent g+xsi je suis dans le bon groupe ou o+x. Je -perm -u=xtrouverai en fait beaucoup de fichiers que l'utilisateur ne peut pas exécuter, et en manquera quelques-uns que l'utilisateur peut exécuter. "
mklement0

1
@IonoclastBrigham: Bien que devoir citer {}soit une nécessité hypothétique (et citer ne fait pas de mal), en pratique, ce n'est pas nécessaire dans les shells de type POSIX et csh. Savez - vous des coquillages où il est est nécessaire?
mklement0

4
@IonoclastBrigham: Intéressant, merci; donc, in fish, {}doit en effet être échappé comme soit '{}'ou \{\}. Notez que bash, kshet zshfournissez le même type d'expansion d'accolades; cependant, ils impriment le jeton sans guillemets {} tel quel (et donc: pas besoin d'échapper), car ils ne le considèrent PAS comme une expression d'accolade valide (ils nécessitent au moins 2 jetons, ou une expression de séquence numérique valide), alors qu'ils fish considèrent {}une accolade valide expression qui aboutit à la chaîne vide .
mklement0

9

Vous pouvez utiliser l' -executableindicateur de test:

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

4
-executable est censé être une option inconnue.
fait

4
Serait-ce une extension GNU Find? Puisque la balise est Unix, pas Linux, au moins une extension GNU doit être documentée comme telle.
Jonathan Leffler

3
Cette option n'est pas prise en charge par la commande BSD find trouvée au moins sur OS X. Il s'agit d'une extension GNU, mais pourrait être prise en charge par d'autres versions de find.
Ionoclast Brigham

FWIW, j'ai trouvé que ce n'était pas sur sles 10, mais sur sles> = 11 (je me suis un peu brûlé)
Peter Turner

Notez que cela n'obtient pas réellement tous les exemples. Dans mon cas, j'avais un fichier que je possédais car -rw-r-xr-xqui -executablene détecte pas
Dezza

2

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

13
Seulement quelques milliers de boîtiers de plus, et vous les aurez réinventés file!
tripleee

@tripleee +1. Cool serait cette extension:find ./ -mime application/x-sharedlib -o -mime application/x-dosexec
Daniel Alder

@Daniel Alder, quelle version de Find que vous utilisez? Je n'ai pas trouvé l'option -mime dans find (GNU findutils) 4.4.2
AjayKumarBasuthkar

@tripleee +1. utiliser 'file' et / 'mimetype' est une bonne idée ou découvrir la version de recherche qui prend en charge -mime est meilleure, se demandant également si 'file' / 'mimetype' ont l'option de filtrer et d'afficher uniquement les exécutables.
AjayKumarBasuthkar

2
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.


1

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!


Bon à savoir mdfindsur OSX. Notez que votre commande signale les exécutables Unix pour l' ensemble du système . mdfind -onlyin . 'kMDItemContentType=public.unix-executable'limite les résultats au sous-arbre du répertoire courant. Points d'intérêt mineurs: limiter la recherche à un répertoire spécifique uniquement (sans sous-dossiers) n'est apparemment pas pris en charge. Les liens symboliques vers les fichiers exécutables ne sont apparemment jamais inclus. Curieusement, une fois mdfindqu'un fichier a été trouvé comme exécutable, la suppression du bit exécutable n'est pas prise en compte.
mklement0

Je pense avoir trouvé des bogues dans la façon dont Spotlight détecte / non-détecte les fichiers exécutables Unix; J'ai déposé un bogue avec Apple, ainsi que sur openradar.me/20162683 . Je vous encourage - et toute personne intéressée d' autre dans cette fonctionnalité - déposer également un bug à bug à bugreport.apple.com
mklement0

(Désolé pour la rafale de commentaires; j'espère qu'ils sont corrects maintenant) mdfind -onlyin . 'kMDItemContentType=public.unix-executable'se comporte comme le find . -type f -perm +111 -printfait. Autrement dit, il trouve des fichiers avec n'importe quel ensemble de bits exécutables, ce qui peut donner des faux positifs (bien que cela ne pose pas de problème dans la pratique) - pour ne vraiment trouver que les fichiers exécutables par l' utilisateur actuel à l' aide de BSD find, voir la réponse de @ gniourf_gniourf. L'utilisation d'une findsolution basée sur une base de données présente l'avantage que vous pouvez également trouver des liens symboliques vers des fichiers exécutables, si vous le souhaitez (option -L), ce qui mdfindsemble impossible.
mklement0

1
@ mklement0 ma réponse a évité les embellissements - pour essayer de clouer le point à la maison - mais oui, vous n'utiliseriez presque jamais cette forme "sans garantie". une autre option - je ne sais pas si c'est le cas - est un bon vieux globbing .. ls /Applications/**/*(*)dans votre (ma?) zshcoquille
Alex Gray

Merci pour le zshconseil pratique - je ne le savais pas; (il semble que vous puissiez trouver des exécutables ( *) ou des liens symboliques ( @), mais pas les deux, non?). Quant à votre point d'origine: find . -type f -perm +a=xpermettez- moi de répéter: fera ce que fait votre mdfindcommande, tout en offrant plus de flexibilité. Vous pouvez même le reformuler pour qu'il soit conforme à POSIX.
mklement0

1

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.


1

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.


0

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)
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.