On Wed, Apr 20, 2005 at 08:22:26AM +0200, Daniel Cordey wrote:
> etendu, mais plus lent. Cette derniere commande donne les moyens de limiter
pour la lenteur de find: c'est juste, c'est d� au fait que la forme:
> find . -uid 500 -name \*.py -exec rm {} \;
va ex�cuter (de mani�re s�re) N fois une commande. exec*() sur UNIX a
beau �tre rapide (caches, copy-on-write, etc), si on l'ex�cute 100'000
fois on arrive malgr� tout � des performances m�diocres.
Solution interm�diaire:
xargs est une commande qui prend des donn�es sur stdin et ex�cute
la commande donn�e en param�tre avec � chaque fois un certain nombre
des donn�es sur stdin pass�s comme arguments.
(en bref ici: il y aura N/X ex�cutions de rm, au lieu de N dans le
cas ci-dessus, X d�pendant de la taille maximum de la ligne de
commande et de la taille des arguments, X autocalcul� par xargs).
find . -uid 500 -name \*.py -print0 \
| xargs -0 rm
(on peut supprimer le -0 si l'on est s�r qu'il n'y a pas de s�parateurs
dans les noms de fichiers, comme des espaces ou des sauts de ligne)
inconv�nient:
- erreur si aucun fichier correspondant trouv�
work-around: xargs -0 rm -f unexistant
- difficile de d�tecter une erreur dans l'ex�cution de find
work-around: passer par un fichier temporaire ou un tube nomm�
et tester les codes de retour.
> Ainsi, je peux m'assurer que je n'ai pas d'autres fichiers "oublies" dans la
> structure... Ensuite seulement, je substitue 'ls -l' par mon rm. Ceci
> s'applique a toutes les commandes shell du style rm, cp, mv, chown, etc.
Le risque de s�curit� g�n�ral sur un syst�me multi-utilisateur est li� �
des modifications des donn�es entre ces deux phases, en particulier des
m�tadonn�es si les commandes cit�es travaillent sur la destination des
liens symboliques (pas le cas de GNU chown � ce que j'ai vu).
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
