Discussion :

[renaud26]

Bonjour à tous,

Je souhaiterais rechercher une ligne particulière dans tous les fichiers du serveur. Cette ligne est du genre :

/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so

J'ai vu que la commande GREP pouvait faire ce genre de choses. J'ai essayé avec l'option -x mais on dirait que ça rame et que rien ne sort. Mais je voulais éviter les fichiers "permission denied" et autres inaccessibles.

Quelle serait la bonne méthode ?
Peut-être pas GREP ? Une autre option ?
Merci de vos lumières.

[becket]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
find /CHEMIN  -type f -exec grep -l LIGNERECHERCHEE {} \; 2> /dev/null

[renaud26]

Bonsoir et merci de ta réponse,

Comme je suis débutant, peux tu me préciser :

find /CHEMIN -type f -exec grep -l LIGNERECHERCHEE {} \; 2> /dev/null

CHEMIN : si je veux une recherche complète, je dois mettre /root ?

Ce qui donnerait, pour mon exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
find /root  -type f -exec grep -l /usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so  {} \; 2> /dev/null

Ni guillemets ni apostrophe autour de LIGNE RECHERCHEE ?

[chardclo]

bonsoir,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grep -lR '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so' / 2>/dev/null

[renaud26]

Bonsoir, merci de ton passage.

Ton expression est différente. Du coup...


Je suis un peu paumé.
Je la teste. C'est sans danger pour le serveur ?

[frp31]

Bonsoir, merci de ton passage.

Ton expression est différente. Du coup...


Je suis un peu paumé.
Je la teste. C'est sans danger pour le serveur ?

grep ne fait que "lire" du contenu et l'afficher il ne modifie rien.

[Sve@r]

Je la teste. C'est sans danger pour le serveur ?

Salut
Aucune action que tu peux faire n'est dangereuse pour le serveur (ou pour toute machine Unix) si
1) les droits ont bien été positionnés (ou simplement pas été ouverts par rapport aux droits mis par défaut)
2) si tu prends soin de ne jamais bosser sous root (devenir root ponctuellement pour un besoin précis oui, mais pas bosser de façon généralisée sous root)

Ton expression est différente. Du coup...


Je suis un peu paumé.

becket a utilisé un mix de 2 commandes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

find /chemin-type f -exec grep -l LIGNERECHERCHEE {} \; 2> /dev/null

1) la commande find qui permet de rechercher des fichiers à partir d'un point de départ "/chemin". Ici il demande la recherche de tout fichier classique "-type f" (on n'espère pas trouver une chaine dans un dossier ou un fichier spécial).
2) chaque fichier trouvé sera passé via "-exec" à la commande "grep" qui cherchera "lignecherchée" dans le fichier trouvé par find, fichier symbolisé par les accolades {}. Pour que find sache où s'arrête la commande "grep", il faut la terminer par un point-virgule mais ce point-virgule ne doit pas être intercepté par ton interpréteur shell donc on le protège par un backslash.

Et enfin il se peut que tu n'aies pas accès à toute l'arborescence (cause droits). Dans ce cas, find n'y a pas accès non plus et te renvoie un message disant qu'il ne peut pas y accéder, ce message transitant par le canal des erreurs n° 2. Pour ne pas que ce message te gêne, on le redirige dans /dev/null

chardclo utilise une commande grep un peu plus élaborée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grep -lR '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so' / 2>/dev/null

Il demande ici à grep d'assurer lui-même la recherche récursive avec l'option "-R". Bref il demande à grep de faire le travail de find.
Certaines commandes ont été en effet reprises pour faire un peu plus que les commandes d'origine.

La syntaxe de becket est une syntaxe généraliste, très dans le principe Unix qui dit qu'une commande ne fait qu'un travail mais le fait bien et c'est en les mixant ou les reliant plusieurs commandes les unes aux autres qu'on peut faire des traitements complexe. Cette syntaxe marchera sur tous les Unix du monde quel que soit ton besoin.
La syntaxe de chardclo est une syntaxe utilisant certaines commandes souvent utilisées dans certaines configuration qui ont alors été optimisées pour pouvoir intégrer elles-mêmes la configuration en question sans passer par une autre commande préalable. Ca ne marchera que dans des cas très spécifiques (sur les Unix récents pour une configuration précise)

Et ce matin, 12h00 plus tard, le curseur est toujours sous l'instruction et rien ne s'est affiché, comme si il devait "scanner" 1 milliard de lignes. Pourtant le serveur n'a encore aucun site installé...
Normal ou étrange?

Pour moi c'est normal. chardclo a oublié que sa commande allait scanner tous les fichiers de l'arborescence, y compris les pipes. Or, tout processus qui lit un pipe reste bloqué tant qu'un autre processus ne vient pas y écrire dedans...
A moins que grep -R sache éviter les pipes et dans ce cas mon hypothèse n'est pas bonne (je ne connais pas les détails de l'option "-R"). Mais tu devrais essayer la syntaxe de becket pour voir car avec la sienne, en ne demandant que les fichiers de type f, tu es sûr de ne pas choper les fichiers de type p...

CHEMIN : si je veux une recherche complète, je dois mettre /root ?

Si tu mets /root ta recherche ne débutera qu'à partir de /root. Si tu veux une recherche sur toute l'arborescence, il faut mettre la base de l'arborescence donc "/"

Je ne vois pas défiler de lignes, façon "scanner"

Unix est un système de professionnels et non une série grand guignolesque à la façon des experts Miami. Il ne t'affiche que les infos que tu demandes et les infos d'échec...

Mais ça fait maintenant 36 heures... Il y a tant que ça de fichiers à passer au crible ?

36 heures !!!??? Si une commande aussi basique qu'un grep tourne plus de 10 minutes tu peux l'arrêter, c'est qu'il y a un problème ; probablement le coup des pipes. Comme quoi parfois, les principes de nos sages ancêtres Unixiens avaient du bon et essayer de vouloir "gonfler" artificiellement certaines commandes en oubliant certains détails amène plus de malheurs qu'autre chose...