Utilisation de grep [Résolu]

[julien.63]

Salut,
je dois chercher tous les fichiers dont le nom contient audubon ou dans lequel se trouve le mot "audubon".
Pour la première recherche j'ai fait ça :

Code :

root@STRI-DB01:~# find / | grep audubon

ce qui m'a sorti une petite quinzaine de fichier. Donc je pense que c'est bon.

Par contre je n'arrive pas à écrire la commande GREP pour scanner l'intérieur des fichiers.
J'ai essayé plusieurs trucs mais ça ne me donne aucun résultat. Je trouve ça plutot louche et je pense que je dois m'y prendre.

Code :

1
2
3
4
root@STRI-DB01:/# grep -l audubon *
-- pas de résultat --
root@STRI-DB01:/# grep -l audubon /*
-- pas de résultat --

Merci d'avance pour vos conseils.

[Michaël]

ça va être carrément plus long comme recherche

Code :

1
2
3
4
5
6
7
8
9
10
11
#!/bin/sh
 
for i in $(find / -type f); do
    echo -n "Scanne $i : "
    OUTPUT=$(cat $i|grep audubon)
    if [ ${#OUTPUT} = 0 ]; then
    echo "rien"
    else
    echo "oui"
    fi
done

le ${#VAR} permet de tester la longueur de VAR. si c'est 0, alors c'est que grep n'a rien trouvé

[ripat]

Et pourquoi pas simplement:

Code :

grep -r audubon *

-r pour scanner récursivement le contenu de tous les fichiers du répertoire courant. Tu peux éventuellement y rajouter l'option -i pour rendre la recherche insensible à la casse.

[MarcG]

avec le find et le grep :

Code :

1
2
 
find . -type f -name "*audubon*" -exec grep -H -w audubon {} ;\

te sort tout les fichiers comportant le mot audubon (mot au sens unix) et dont le nom comporte la chaine audubon.

[chaval]

tu veux chercher une chaine à l'interieur d'un seul fichier ?

Code :

cat fichier | grep chaine

[MarcG]

Envoyé par chaval

tu veux chercher une chaine à l'interieur d'un seul fichier ?

Code :

cat fichier | grep chaine

pourquoi faire un | et un cat ? pour faire gigotter le CPU ?

Code :

grep chaine fichier

tel et la syntaxe donnée dans le man !

[becket]

find ./ -name "*.audubon*" -or -exec grep -l audubon {} \;

Soit le nom contient audubon, soit le contenu du fichier contient audubon

[chaval]

Envoyé par MarcG

pourquoi faire un | et un cat ? pour faire gigotter le CPU ?

Tu sais, je suis adepte des methodes dites "a l'américaine"

[ripat]

Envoyé par chaval

Tu sais, je suis adepte des methodes dites "a l'américaine"

[troll]Pas si mauvaise que ça finalement! [/troll]

Pour en avoir le coeur net, j'ai fait un petit bench sur les deux syntaxes. Un bête grep sur un gros fichier log (22 Mo).

Code :

1
2
3
4
5
6
7
8
9
10
#! /bin/sh
#
#
export TIME="TIME\n\t%E real\n\t%U user\n\t%S sys\nCPU\n\t%P cpu\nMEM\n\t%K Kb\n---------------------"
 
/usr/bin/time -o tmp_time  grep '192.168.0.151' /var/log/apache2/access.log.1
/usr/bin/time -o tmp_time -a  cat /var/log/apache2/access.log.1 | grep '192.168.0.151'
 
cat tmp_time
rm -f tmp_time

Résultat:

TIME
0:01.46 real
0.30 user
0.10 sys
CPU
27% cpu
MEM
0 Kb
---------------------
TIME
0:01.44 real
0.00 user
0.01 sys
CPU
0% cpu
MEM
0 Kb
---------------------

Le CPU semble moins "gigoter" avec la méthode américaine.

Curieux non? Le CPU load est calculé en prenant le :

Percentage of the CPU that this job got. This is just user + system times divided by the total running time

Le cat + pipe, moins élégant c'est vrai, ne semble rien envoyer dans le user space d'où son bon résultat.

[chaval]

Envoyé par ripat

[troll]Pas si mauvaise que ça finalement! [/troll]
Le CPU semble moins "gigoter" avec la méthode américaine.

Tu sais, l'élégance, je m'en fiche lol... Le CPU qui gigote aussi, je fais rarement des recherches sur des fichhiers de plus d'1Mo, au pire, j'utilise VI

Je suis un partisan du moindre effort, pourquoi parcourir un man de 40 pages ou retenir une commande à rallonga alors qu'un "cat | grep" s'écrit en un rien de temps

Le prochaine fois, je penserai à toi

[al1_24]

Les différences de temps de traitement peuvent aussi s'expliquer parce que lors de l'exécution de la seconde commande, le ficheir traité a déjà été lu et est resté en cache.
Essaye d'inverser les commandes avant de relancer ton test de comparaison de temps de traitement...

[ripat]

Envoyé par al1_24

Les différences de temps de traitement peuvent aussi s'expliquer parce que lors de l'exécution de la seconde commande, le ficheir traité a déjà été lu et est resté en cache.
Essaye d'inverser les commandes avant de relancer ton test de comparaison de temps de traitement...

J'y avais pensé aussi et l'inversion des commandes ne change pas le résultat.

Je n'y attacherais pas trop d'importance car la manière dont est calculée la charge du CPU ne me semble pas très réaliste. Ce qui compte, finalement c'est le temps CPU total. Et, sur ce plan, les deux manières se valent.

[julien.63]

salut,
j'avoue que je n'en suis pas à comparer laquelle des solutions est la plus rapide.
Mais quoiqu'il en soit merci à tous, j'ai trouvé mes fichiers grâce à vous.
@+