Discussion :

[bougnbie]

Bonjour,
J'ai dans un repertoire des centaines de milliers de fichiers txt, et je voudrais supprimer tous les fichiers de moins de 3 lignes.

Je cherche un moyen efficace de la faire.

Je pense à un truc du genre:

Code :

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

1
2
3
4
5
6
7
8
9
 
for i in `ls *.txt`;
do
nb=`wc -l $i`
if [nb -le 3]
then
`rm - f $i`
 fi
done

Mais je ne sais pas ce que ça vaut en efficacité, vu que c'est sur des millions de fichiers (un peu moins).

Peut être que faire ça en perl est préférable?

Merci d'avance.

[N_BaH]

Bonjour,,

ON N'UTILISE PAS ls DANS LES SCRIPTS !!!
parce que les noms de fichiers peuvent contenir des caractères contenus dans l'IFS, qui feront itérer la boucle for sur chaque mot du nom du fichier.

pour des traitements textuels, perl est beaucoup plus rapide que le shell.
mais ici, de toutes manières, il faut boucler sur les fichiers pour déterminer le nombres de lignes, je doute que perl apporte quelque gain que ce soit.

en propre, ton script :

Code :

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

1
2
3
4
for f in *.txt
do
   test -f "$f" && test $(wc -l < "$f") -le 3 && rm -f "$f"
done

[bougnbie]

merci beaucoup!

Effectivement, mon code était très sale, j'ai tapé ça depuis une tablette, c'était plus du pseudo-code...

Merci en tout cas, je vais faire ça.

[JeitEmgie]

je doute que perl apporte quelque gain que ce soit.

n'importe quelle solution qui ne comptera pas plus de lignes que le maximum recherché (ici 3) - éventuellement MAX+1 avec un head -n en amont du wc -l - sera théoriquement plus efficace que wc seul qui lui lira toujours TOUT le fichier.

[jack-ft]

n'importe quelle solution qui ne comptera pas plus de lignes que le maximum recherché (ici 3) - éventuellement MAX+1 avec un head -n en amont du wc -l - sera théoriquement plus efficace que wc seul qui lui lira toujours TOUT le fichier.

Ben, effectivement, théoriquement, ça paraît séduisant!...
sauf qu'il faut comparer avec le surcoût dû au fork pour lancer le process 'head'!

En gros, s'il y a des millions de fichiers qui font, en majorité, entre moins de 3 lignes et "pas beaucoup plus" (notez la précision mathématique!), il vaut mieux utiliser le wc SANS head.
S'il y a des millions de fichiers, dont quelques uns font moins de 3 lignes et "beaucoup d'autres" font "beaucoup plus" (par exemple, plusieurs millions de lignes), alors probablement (avec une probabilité probablement substantiellement supérieure à 1/2 (notez la précision mathématique!)) qu'il vaut mieux utiliser le wc AVEC head.

Entre les deux, mon coeur balance...

Le mieux, c'est de tester préalablement les 2 méthodes pour voir laquelle est la plus efficace!!! (joke )

[ok.Idriss]

(joke )

Ben non pourquoi pas ? Ça se fait des tests de perf pour ce genre de petits détails (ça peux avoir un impacte sur de très grosses volumétries sérieusement).

[JeitEmgie]

Ben, effectivement, théoriquement, ça paraît séduisant!...
sauf qu'il faut comparer avec le surcoût dû au fork pour lancer le process 'head'!

En gros, s'il y a des millions de fichiers qui font, en majorité, entre moins de 3 lignes et "pas beaucoup plus" (notez la précision mathématique!), il vaut mieux utiliser le wc SANS head.
S'il y a des millions de fichiers, dont quelques uns font moins de 3 lignes et "beaucoup d'autres" font "beaucoup plus" (par exemple, plusieurs millions de lignes), alors probablement (avec une probabilité probablement substantiellement supérieure à 1/2 (notez la précision mathématique!)) qu'il vaut mieux utiliser le wc AVEC head.

Entre les deux, mon coeur balance...

Le mieux, c'est de tester préalablement les 2 méthodes pour voir laquelle est la plus efficace!!! (joke )

J'ai dit "éventuellement avec un head" pas que c'était LA solution,
le mieux reste un petit script en Perl (ou autre, vous pouvez aussi faire le tool en C et le compiler) qui prend en paramètres :
le nombre de lignes à tester, le nom du fichier
et qui renvoit 1 ou 0 en fonction de la satisfaction ou non du critère.

[Sve@r]

Ben, effectivement, théoriquement, ça paraît séduisant!...
sauf qu'il faut comparer avec le surcoût dû au fork pour lancer le process 'head'!

En gros, s'il y a des millions de fichiers qui font, en majorité, entre moins de 3 lignes et "pas beaucoup plus" (notez la précision mathématique!), il vaut mieux utiliser le wc SANS head.
S'il y a des millions de fichiers, dont quelques uns font moins de 3 lignes et "beaucoup d'autres" font "beaucoup plus" (par exemple, plusieurs millions de lignes), alors probablement (avec une probabilité probablement substantiellement supérieure à 1/2 (notez la précision mathématique!)) qu'il vaut mieux utiliser le wc AVEC head.

Entre les deux, mon coeur balance...

Bonjour

Ben ne balance plus et tente une autre approche. On pourrait par exemple utiliser un find pour ne cibler que les fichiers qui, a priori, feront moins de 3 lignes...

Considerons qu'une ligne d'un fichier texte fait traditionnellement 80car, cela ferait 240 caracteres pour 3 lignes. Une petite marge de securite (disons 1000 ou soyons riche et montons jusqu'a 5000) et on peut faire un truc de ce style

Code sh :

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

1
2
3
4
find rep -type f -name "*.txt" -size -5000 | while read f
do
    test $(wc -l "$f") -le 3 && rm -f "$f"
done

La taille du fichier etant stockee dans l'inode, la recherche sera tres rapide et cela evitera les problemes lies au wc sur de gros fichiers...

ON N'UTILISE PAS ls DANS LES SCRIPTS !!!

Arf, toujours cette bonne blague

parce que les noms de fichiers peuvent contenir des caractères contenus dans l'IFS, qui feront itérer la boucle for sur chaque mot du nom du fichier.

Mougnou qu'il est mignon quand il fait sa grosse colere

Code sh :

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

1
2
3
4
ls rep | while read f
do
    traitement "$f"
done

PS: les bons programmeurs respectent les regles, les programmeurs brillants les transgressent parfois...

[N_BaH]

le programmeur brillant devrait ne pas gaspiller les ressources, et
donc, ne pas ajouter de commandes et de sous-shells superflus.
(ça, je l'ajouterai à mon prochain coup de gueule systématique)

[disedorgue]

Bonjour,

Comment doit on considérer un fichier avec de plus de 3 lignes mais des lignes vides ?

Cordialement.

[bougnbie]

Pour mon problème initial, j'ai parlé à un grand manitou du shell/perl qui m'a griffonné une solution plus efficace (optimal je pense) que les propositions que j'ai eu ici, je vous la met si vous êtes interessés:

Code :

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

find ./ -exec perl -ne '$. <=3 or exit 1' {} \; -type -f -exec rm {} \;

La tache est exécutée récursivement

[Sve@r]

Pour mon problème initial, j'ai parlé à un grand manitou du shell/perl qui m'a griffonné une solution plus efficace (optimal je pense) que les propositions que j'ai eu ici, je vous la met si vous êtes interessés:

Code :

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

find ./ -exec perl -ne '$. <=3 or exit 1' {} \; -type -f -exec rm {} \;

Bonjour
En ce qui concerne le "plus optimal" je n'en suis pas certain. Je ne connais pas perl mais je suppute que $. contient le nb de lignes. Toutefois ce nb n'etant stocke nulle part, il faut bien que perl le cherche par lui-meme et donc qu'il ouvre le fichier, compte les lignes (les "\n") ce qui prendra au mieux autant de temps que wc et au pire plus de temps (apres tout, wc est dedie a ce travail alors que perl est fait pour faire beaucoup d'autres choses donc plus gros donc plus lourd a se charger). Faut pas confondre "plus court a ecrire" et "plus optimal en temps cpu"...

En plus le type est demande apres le -perl donc (a verifier) si celui-ci ne serait pas lance aussi inutilement sur les autres types de fichiers...

La tache est exécutée récursivement

Euh oui enfin je ne vois pas l'utilite vu que find travaille deja en recursif sur toute l'arborescence...

[disedorgue]

Bonjour,

En fait le perl sort dés qu'il dépasse les 3 lignes avec en plus un status d'erreur si plus grand donc potentiellement, il peut être plus rapide que wc + verification du nombre de ligne.
Mais là, je trouve que c'est sortir l'artillerie lourde. un simple awk à la place du perl serait amplement suffisant et je pense plus optimum.

En gardant la même ligne (écrite dans le bon sens) mais en remplaçant perl par awk, cela donnerait quelque chose du genre:

Code :

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

find ./ -type f -exec awk 'NR > 3 { exit 1 }' {} \; -exec rm {} \;

Cordialement.

[Sve@r]

Bonjour,

En fait le perl sort dés qu'il dépasse les 3 lignes avec en plus un status d'erreur si plus grand donc potentiellement, il peut être plus rapide que wc + verification du nombre de ligne.

Mais sort-il pendant le comptage des que $. depasse 3 ou apres avoir compte le tout ???

Mais là, je trouve que c'est sortir l'artillerie lourde. un simple awk à la place du perl serait amplement suffisant et je pense plus optimum.

awk aussi est super enorme non ???

En gardant la même ligne (écrite dans le bon sens) mais en remplaçant perl par awk, cela donnerait quelque chose du genre:

Code :

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

find ./ -type f -exec awk 'NR > 3 { exit 1 }' {} \; -exec rm {} \;

Cordialement.

Moi je tenterais bien un truc de ce genre (syntaxe approximative)

Code :

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

find ./ -type f -size -5000 -exec \$(wc -l {}) -le 3 && rm -f {}\;

[JeitEmgie]

Mais sort-il pendant le comptage des que $. depasse 3 ou apres avoir compte le tout

il sort dès que la condition est fausse :

$. The current input line number of the last filehandle that was read.

Code :

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

1
2
3
4
5
6
7
 
perl -ne 'print $., "\n" ; $.<=3 or exit 1' A_VERY_BIG_TEXT_FILE ; echo "result" $?
1
2
3
4
result 1

Code :

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

1
2
3
4
 
perl -ne 'print $., "\n" ; $.<=3 or exit 1' A_ONE_LINE_TEXT_FILE ; echo "result" $?
1
result 0

[disedorgue]

Mais sort-il pendant le comptage des que $. depasse 3 ou apres avoir compte le tout ???


awk aussi est super enorme non ???



Moi je tenterais bien un truc de ce genre (syntaxe approximative)

Code :

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

find ./ -type f -size -5000 -exec \$(wc -l {}) -le 3 && rm -f {}\;

Pas aussi simple avec wc car celui-ci ne donne pas que la valeur, il fournit aussi le nom du fichier, il faut donc tronquer le résultat
Sous cygwin (désolé, honte sur moi, pas de linux à la maison), awk prend environ 15% de plus que wc pour compter le nombre de ligne d'un fichier et perl environ 20% mais je reconnais que sous cygwin c'est pas super parlant

[N_BaH]

Pas aussi simple avec wc car celui-ci ne donne pas que la valeur

si, si, il faut rediriger le fichier vers wc (regarde mon message).

[bougnbie]

attention, $. ne contient pas le nombre de ligne mais la valeur de l'itération actuelle, donc dés que le 3 est dépassé, on passe à une autre itération.

la solution avec awk est une copie conforme de celle donnée en perl. je viens de tester, ça met 8 secondes de plus que perl, soit 180 secondes.
Perl fini ça en 172 secondes, j'imagine que ce n'est pas parlant comme différence.

Par contre les solutions avec wc dépassent toute les 400 secondes.
Le fait est qu'il y a beaucoup de fichiers très longs.
(tout ça sur environ 200 000 fichiers).

[bougnbie]

"Euh oui enfin je ne vois pas l'utilite vu que find travaille deja en recursif sur toute l'arborescence..."

C'est bien le find qui le fait récursivement. Je l'ai seulement précisé au cas ou.

[disedorgue]

si, si, il faut rediriger le fichier vers wc (regarde mon message).

Je suis d'accord avec toi sur ta procédure

Par contre, je n'arrive pas à l'écrire directement dans le find, et je suis preneur de la réponse qui pourrait m'arranger dans d'autre cas

attention, $. ne contient pas le nombre de ligne mais la valeur de l'itération actuelle, donc dés que le 3 est dépassé, on passe à une autre itération.

la solution avec awk est une copie conforme de celle donnée en perl. je viens de tester, ça met 8 secondes de plus que perl, soit 180 secondes.
Perl fini ça en 172 secondes, j'imagine que ce n'est pas parlant comme différence.

Par contre les solutions avec wc dépassent toute les 400 secondes.
Le fait est qu'il y a beaucoup de fichiers très longs.
(tout ça sur environ 200 000 fichiers).

Interressant de voir perl gagner, car sur de petit tests (une petite vingtaine de fichiers), sur cygwin, c'est awk qui gagne et en essayant sur un linux que j'ai actuellement sous la main, c'est aussi awk le gagnant.

Cordialement.