find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo). -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
Eric Jacoboni <jaco@teaser.fr> wrote:
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ;
Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour
chaque fichier trouvé tandis que ma solution ne lance qu'un processus
pour tous les fichiers (grosso modo).
--
Martin Jourdan
Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo). -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
FiLH
(Martin Jourdan) writes:
Eric Jacoboni wrote:
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo).
Heu.. les rm commencent-ils dès le premier fichier ?
Quand on a besoin de place VITE, on efface au plus vite.
FiLH, l'efficacité absolue est relative au pb que l'on veut traiter :)
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Martin.Jourdan@free.fr (Martin Jourdan) writes:
Eric Jacoboni <jaco@teaser.fr> wrote:
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ;
Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour
chaque fichier trouvé tandis que ma solution ne lance qu'un processus
pour tous les fichiers (grosso modo).
Heu.. les rm commencent-ils dès le premier fichier ?
Quand on a besoin de place VITE, on efface au plus vite.
FiLH, l'efficacité absolue est relative au pb que l'on veut traiter :)
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo).
Heu.. les rm commencent-ils dès le premier fichier ?
Quand on a besoin de place VITE, on efface au plus vite.
FiLH, l'efficacité absolue est relative au pb que l'on veut traiter :)
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Schmurtz
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo).
Il n'y a pas de limitation du nombre de fichiers avec xargs ? Je pose la question car dans le terminal, si la taille de la commande est trop importante, il renvoie un message d'erreur.
-- Schmurtz
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ;
Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour
chaque fichier trouvé tandis que ma solution ne lance qu'un processus
pour tous les fichiers (grosso modo).
Il n'y a pas de limitation du nombre de fichiers avec xargs ? Je pose la
question car dans le terminal, si la taille de la commande est trop
importante, il renvoie un message d'erreur.
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo).
Il n'y a pas de limitation du nombre de fichiers avec xargs ? Je pose la question car dans le terminal, si la taille de la commande est trop importante, il renvoie un message d'erreur.
-- Schmurtz
Philippe Di Valentin
Le 19/10/03 15:40, Martin Jourdan écrivait:
Eric Jacoboni wrote:
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo). Plutot grosso que modo,encore que:-)))))
-- Philippe
Le 19/10/03 15:40, Martin Jourdan écrivait:
Eric Jacoboni <jaco@teaser.fr> wrote:
find . -name .DS_Store -print | xargs rm -f
find . -name .DS_Store -exec rm {} ;
Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour
chaque fichier trouvé tandis que ma solution ne lance qu'un processus
pour tous les fichiers (grosso modo).
Plutot grosso que modo,encore que:-)))))
find . -name .DS_Store -exec rm {} ; Soit un poil plus court... ;-)
oui mais beaucoup moins efficace car cela lance un processus "rm" pour chaque fichier trouvé tandis que ma solution ne lance qu'un processus pour tous les fichiers (grosso modo). Plutot grosso que modo,encore que:-)))))
-- Philippe
Martin.Jourdan.nospam
Schmurtz wrote:
Il n'y a pas de limitation du nombre de fichiers avec xargs ? Je pose la question car dans le terminal, si la taille de la commande est trop importante, il renvoie un message d'erreur.
xargs connaît la taille maximale d'une ligne de commande donc : - il ouvre une première ligne avec ses propres arguments (ici 'rm -f ') ; - pour chaque nom de fichier qu'il reçoit sur son entrée standard, il commence à comparer sa longueur avec la place disponible sur la ligne qu'il est en train de remplir ; - si ça rentre, il ajoute le nom du fichier lu à la ligne en cours de construction ; - sinon, il envoie la ligne courante à un shell, ouvre une nouvelle ligne de commande avec ses propres arguments et y ajoute le nom du fichier ; - quand son entrée standard est épuisée, il envoie la ligne courante à un shell.
Faites le test suivant : find . -type f -print | xargs wc -l sur un répertoire contenant beaucoup de fichiers, vous verrez apparaître de temps en temps des lignes "total" indiquant qu'un wc se termine...
C'est pour cela que je disais "grosso modo" dans mon post précédent : s'il y a *vraiment* beaucoup de fichiers, xargs peut être amené à lancer plus d'un processus.
Je hope que ça helpe. -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
Schmurtz <moi@ici.com> wrote:
Il n'y a pas de limitation du nombre de fichiers avec xargs ? Je pose la
question car dans le terminal, si la taille de la commande est trop
importante, il renvoie un message d'erreur.
xargs connaît la taille maximale d'une ligne de commande donc :
- il ouvre une première ligne avec ses propres arguments (ici 'rm -f ')
;
- pour chaque nom de fichier qu'il reçoit sur son entrée standard, il
commence à comparer sa longueur avec la place disponible sur la ligne
qu'il est en train de remplir ;
- si ça rentre, il ajoute le nom du fichier lu à la ligne en cours de
construction ;
- sinon, il envoie la ligne courante à un shell, ouvre une nouvelle
ligne de commande avec ses propres arguments et y ajoute le nom du
fichier ;
- quand son entrée standard est épuisée, il envoie la ligne courante à
un shell.
Faites le test suivant :
find . -type f -print | xargs wc -l
sur un répertoire contenant beaucoup de fichiers, vous verrez apparaître
de temps en temps des lignes "total" indiquant qu'un wc se termine...
C'est pour cela que je disais "grosso modo" dans mon post précédent :
s'il y a *vraiment* beaucoup de fichiers, xargs peut être amené à lancer
plus d'un processus.
Je hope que ça helpe.
--
Martin Jourdan
Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
Il n'y a pas de limitation du nombre de fichiers avec xargs ? Je pose la question car dans le terminal, si la taille de la commande est trop importante, il renvoie un message d'erreur.
xargs connaît la taille maximale d'une ligne de commande donc : - il ouvre une première ligne avec ses propres arguments (ici 'rm -f ') ; - pour chaque nom de fichier qu'il reçoit sur son entrée standard, il commence à comparer sa longueur avec la place disponible sur la ligne qu'il est en train de remplir ; - si ça rentre, il ajoute le nom du fichier lu à la ligne en cours de construction ; - sinon, il envoie la ligne courante à un shell, ouvre une nouvelle ligne de commande avec ses propres arguments et y ajoute le nom du fichier ; - quand son entrée standard est épuisée, il envoie la ligne courante à un shell.
Faites le test suivant : find . -type f -print | xargs wc -l sur un répertoire contenant beaucoup de fichiers, vous verrez apparaître de temps en temps des lignes "total" indiquant qu'un wc se termine...
C'est pour cela que je disais "grosso modo" dans mon post précédent : s'il y a *vraiment* beaucoup de fichiers, xargs peut être amené à lancer plus d'un processus.
Je hope que ça helpe. -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
Martin.Jourdan.nospam
FiLH wrote:
Heu.. les rm commencent-ils dès le premier fichier ?
Non, il attend d'avoir trouvé tous les fichiers ou du moins d'en avoir accumulé assez pour remplir une ligne de commande (voir mon autre post dans ce fil).
Quand on a besoin de place VITE, on efface au plus vite.
find et xargs vont très vite : sur mon home-Dir comportant plus de 44000 fichiers dans un disque contenant 16 Go sur 49, "find . -name .DS_Store -print | wc" (ce qui est le plus proche possible d'un find "pur") prend 17 secondes de temps réel pour me trouver les 106 .DS_Store sur mon iMac G4 17" 800 à moi que j'ai avec un disque qui n'est pas un foudre de guerre. Je n'ai pas testé avec le "rm" mais à mon avis, au pire cela double le temps total. 30 secondes, c'est trop ? -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
FiLH <filh@filh.org> wrote:
Heu.. les rm commencent-ils dès le premier fichier ?
Non, il attend d'avoir trouvé tous les fichiers ou du moins d'en avoir
accumulé assez pour remplir une ligne de commande (voir mon autre post
dans ce fil).
Quand on a besoin de place VITE, on efface au plus vite.
find et xargs vont très vite : sur mon home-Dir comportant plus de 44000
fichiers dans un disque contenant 16 Go sur 49, "find . -name .DS_Store
-print | wc" (ce qui est le plus proche possible d'un find "pur") prend
17 secondes de temps réel pour me trouver les 106 .DS_Store sur mon iMac
G4 17" 800 à moi que j'ai avec un disque qui n'est pas un foudre de
guerre. Je n'ai pas testé avec le "rm" mais à mon avis, au pire cela
double le temps total. 30 secondes, c'est trop ?
--
Martin Jourdan
Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
Heu.. les rm commencent-ils dès le premier fichier ?
Non, il attend d'avoir trouvé tous les fichiers ou du moins d'en avoir accumulé assez pour remplir une ligne de commande (voir mon autre post dans ce fil).
Quand on a besoin de place VITE, on efface au plus vite.
find et xargs vont très vite : sur mon home-Dir comportant plus de 44000 fichiers dans un disque contenant 16 Go sur 49, "find . -name .DS_Store -print | wc" (ce qui est le plus proche possible d'un find "pur") prend 17 secondes de temps réel pour me trouver les 106 .DS_Store sur mon iMac G4 17" 800 à moi que j'ai avec un disque qui n'est pas un foudre de guerre. Je n'ai pas testé avec le "rm" mais à mon avis, au pire cela double le temps total. 30 secondes, c'est trop ? -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
FiLH
(Martin Jourdan) writes:
FiLH wrote:
Heu.. les rm commencent-ils dès le premier fichier ?
Non, il attend d'avoir trouvé tous les fichiers ou du moins d'en avoir accumulé assez pour remplir une ligne de commande (voir mon autre post dans ce fil).
Quand on a besoin de place VITE, on efface au plus vite.
find et xargs vont très vite : sur mon home-Dir comportant plus de 44000
C'est peu. (Désolé ).
fichiers dans un disque contenant 16 Go sur 49, "find . -name .DS_Store -print | wc" (ce qui est le plus proche possible d'un find "pur") prend
C'est peu de Go et c'est un disque rapide.
D'autre part quand j'utilise find sur un partagé nfs utilisé en même temps par 80 utilisateurs qui attendent de la place disque, le parcours est un peu plus long que 17 secondes :)
:)
FiLH (Bon je sais sur son mac monoutilisateur à la maison c'est pas pareil)
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Heu.. les rm commencent-ils dès le premier fichier ?
Non, il attend d'avoir trouvé tous les fichiers ou du moins d'en avoir
accumulé assez pour remplir une ligne de commande (voir mon autre post
dans ce fil).
Quand on a besoin de place VITE, on efface au plus vite.
find et xargs vont très vite : sur mon home-Dir comportant plus de 44000
C'est peu. (Désolé ).
fichiers dans un disque contenant 16 Go sur 49, "find . -name .DS_Store
-print | wc" (ce qui est le plus proche possible d'un find "pur") prend
C'est peu de Go et c'est un disque rapide.
D'autre part quand j'utilise find sur un partagé nfs utilisé en
même temps par 80 utilisateurs qui attendent de la place disque, le
parcours est un peu plus long que 17 secondes :)
:)
FiLH (Bon je sais sur son mac monoutilisateur à la maison c'est pas pareil)
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Heu.. les rm commencent-ils dès le premier fichier ?
Non, il attend d'avoir trouvé tous les fichiers ou du moins d'en avoir accumulé assez pour remplir une ligne de commande (voir mon autre post dans ce fil).
Quand on a besoin de place VITE, on efface au plus vite.
find et xargs vont très vite : sur mon home-Dir comportant plus de 44000
C'est peu. (Désolé ).
fichiers dans un disque contenant 16 Go sur 49, "find . -name .DS_Store -print | wc" (ce qui est le plus proche possible d'un find "pur") prend
C'est peu de Go et c'est un disque rapide.
D'autre part quand j'utilise find sur un partagé nfs utilisé en même temps par 80 utilisateurs qui attendent de la place disque, le parcours est un peu plus long que 17 secondes :)
:)
FiLH (Bon je sais sur son mac monoutilisateur à la maison c'est pas pareil)
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Martin.Jourdan.nospam
FiLH wrote:
C'est peu de Go et c'est un disque rapide.
Non ce n'est pas un disque rapide (5400 t/mn)
D'autre part quand j'utilise find sur un partagé nfs utilisé en même temps par 80 utilisateurs qui attendent de la place disque, le parcours est un peu plus long que 17 secondes :)
Tu ne m'avais pas tout dit.
Au boulot aussi j'ai des disques NFS très partagés donc je sais ce que ça veut dire d'attendre. Mais quand on a 80 utilisateurs sur le dos, on ne laisse pas l'occupation grimper jusqu'à 100% sans la surveiller ! -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
FiLH <filh@filh.org> wrote:
C'est peu de Go et c'est un disque rapide.
Non ce n'est pas un disque rapide (5400 t/mn)
D'autre part quand j'utilise find sur un partagé nfs utilisé en
même temps par 80 utilisateurs qui attendent de la place disque, le
parcours est un peu plus long que 17 secondes :)
Tu ne m'avais pas tout dit.
Au boulot aussi j'ai des disques NFS très partagés donc je sais ce que
ça veut dire d'attendre. Mais quand on a 80 utilisateurs sur le dos, on
ne laisse pas l'occupation grimper jusqu'à 100% sans la surveiller !
--
Martin Jourdan
Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
D'autre part quand j'utilise find sur un partagé nfs utilisé en même temps par 80 utilisateurs qui attendent de la place disque, le parcours est un peu plus long que 17 secondes :)
Tu ne m'avais pas tout dit.
Au boulot aussi j'ai des disques NFS très partagés donc je sais ce que ça veut dire d'attendre. Mais quand on a 80 utilisateurs sur le dos, on ne laisse pas l'occupation grimper jusqu'à 100% sans la surveiller ! -- Martin Jourdan Informaticien, fan de Macintosh (X), de Peter Gabriel et de volley-ball
