En faisant le ménage sur une machine, je tombe sur un répértoire de logs
qui contient beaucoup de fichiers, tous inutiles. Après vérification, je
fais donc un brutal rm. Et là...
$ rm *
bash: /bin/rm: Argument list too long
Argh, damned. Je savais qu'il y avait *beaucoup* de fichiers, mais à ce
point !!
(je ne compterais pas le détail, parce que la machine est lente et
vieille, et il met déjà assez de temps à tourner comme ça sans que j'en
rajoute...)
Je suis donc en train d'effacer les fichiers par paquets (rm log.249.*,
puis rm log.250.*, etc.), ce qui marche, mais bon, faut que j'ai déjà une
idée du nom des fichiers.
Est-ce que quelqu'un aurait une idée de comment faire pour tout effacer
d'un coup ?
Et au passage et par curiosité (et pour me donner une idée du nombre de
fichiers que j'ai !), c'est combien cette limite ?
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
La fonction primaire de 'xargs' est justement de répondre à ce problème: 'xargs' construit une série de commandes dont la taille est juste à la limite sans jamais l'atteindre.
C'est pour ça qu'il n'est pas astucieux de remplacer un : tar cvf toto.tar * qui planterait à cause d'un trop grand nombre de fichier par un : ls | xargs tar cvf toto.tar La 2nd commande ne donna pas d'erreur, mais on a que les derniers fichiers ! J'ai d'ailleurs cherché un moment la raison avant de comprendre le conctionnement de xargs ;-)
Paul GABORIT <Paul.Gaborit@invalid.invalid> a écrit sur fr.comp.os.unix :
La fonction primaire de 'xargs' est justement de répondre à ce problème:
'xargs' construit une série de commandes dont la taille est juste à la limite
sans jamais l'atteindre.
C'est pour ça qu'il n'est pas astucieux de remplacer un :
tar cvf toto.tar *
qui planterait à cause d'un trop grand nombre de fichier par un :
ls | xargs tar cvf toto.tar
La 2nd commande ne donna pas d'erreur, mais on a que les derniers
fichiers ! J'ai d'ailleurs cherché un moment la raison avant de
comprendre le conctionnement de xargs ;-)
La fonction primaire de 'xargs' est justement de répondre à ce problème: 'xargs' construit une série de commandes dont la taille est juste à la limite sans jamais l'atteindre.
C'est pour ça qu'il n'est pas astucieux de remplacer un : tar cvf toto.tar * qui planterait à cause d'un trop grand nombre de fichier par un : ls | xargs tar cvf toto.tar La 2nd commande ne donna pas d'erreur, mais on a que les derniers fichiers ! J'ai d'ailleurs cherché un moment la raison avant de comprendre le conctionnement de xargs ;-)
JustMe
Etienne de Tocqueville wrote:
Paul GABORIT a écrit sur fr.comp.os.unix :
La fonction primaire de 'xargs' est justement de répondre à ce problème: 'xargs' construit une série de commandes dont la taille est juste à la limite sans jamais l'atteindre.
C'est pour ça qu'il n'est pas astucieux de remplacer un : tar cvf toto.tar * qui planterait à cause d'un trop grand nombre de fichier par un : ls | xargs tar cvf toto.tar La 2nd commande ne donna pas d'erreur, mais on a que les derniers fichiers ! J'ai d'ailleurs cherché un moment la raison avant de comprendre le conctionnement de xargs ;-)
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
find . -type f -name "*.[ch]" | tar cvf messources.tar --files-from=-
;-)
Etienne de Tocqueville wrote:
Paul GABORIT <Paul.Gaborit@invalid.invalid> a écrit sur fr.comp.os.unix :
La fonction primaire de 'xargs' est justement de répondre à ce problème:
'xargs' construit une série de commandes dont la taille est juste à la limite
sans jamais l'atteindre.
C'est pour ça qu'il n'est pas astucieux de remplacer un :
tar cvf toto.tar *
qui planterait à cause d'un trop grand nombre de fichier par un :
ls | xargs tar cvf toto.tar
La 2nd commande ne donna pas d'erreur, mais on a que les derniers
fichiers ! J'ai d'ailleurs cherché un moment la raison avant de
comprendre le conctionnement de xargs ;-)
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
find . -type f -name "*.[ch]" | tar cvf messources.tar --files-from=-
La fonction primaire de 'xargs' est justement de répondre à ce problème: 'xargs' construit une série de commandes dont la taille est juste à la limite sans jamais l'atteindre.
C'est pour ça qu'il n'est pas astucieux de remplacer un : tar cvf toto.tar * qui planterait à cause d'un trop grand nombre de fichier par un : ls | xargs tar cvf toto.tar La 2nd commande ne donna pas d'erreur, mais on a que les derniers fichiers ! J'ai d'ailleurs cherché un moment la raison avant de comprendre le conctionnement de xargs ;-)
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
find . -type f -name "*.[ch]" | tar cvf messources.tar --files-from=-
;-)
Etienne de Tocqueville
JustMe a écrit sur fr.comp.os.unix :
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun des unix que je fréquente ! Par ailleurs, "tar" est probablement la commande la plus incompatible d'un unix à l'autre que je connaisse. Pour dire, certains arguments ont meme l'effet strictement inverse d'un unix à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option n'est pas envisageable
J'avais donc fini par opter pour un cpio qui est largement plus portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
JustMe <pasdesp@m.merci> a écrit sur fr.comp.os.unix :
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun
des unix que je fréquente ! Par ailleurs, "tar" est probablement la
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour
dire, certains arguments ont meme l'effet strictement inverse d'un unix
à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option
n'est pas envisageable
J'avais donc fini par opter pour un cpio qui est largement plus portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et
non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun des unix que je fréquente ! Par ailleurs, "tar" est probablement la commande la plus incompatible d'un unix à l'autre que je connaisse. Pour dire, certains arguments ont meme l'effet strictement inverse d'un unix à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option n'est pas envisageable
J'avais donc fini par opter pour un cpio qui est largement plus portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
JustMe
Etienne de Tocqueville wrote:
JustMe a écrit sur fr.comp.os.unix :
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour dire, certains arguments ont meme l'effet strictement inverse d'un unix à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option n'est pas envisageable
t'exageres un tantinet ;-)
J'avais donc fini par opter pour un cpio qui est largement plus portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
euh... toto.cpio plutot ;-)
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
C'est des unix ca ? ;-)
Etienne de Tocqueville wrote:
JustMe <pasdesp@m.merci> a écrit sur fr.comp.os.unix :
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun
des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour
dire, certains arguments ont meme l'effet strictement inverse d'un unix
à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option
n'est pas envisageable
t'exageres un tantinet ;-)
J'avais donc fini par opter pour un cpio qui est largement plus portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et
non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
euh... toto.cpio plutot ;-)
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour dire, certains arguments ont meme l'effet strictement inverse d'un unix à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option n'est pas envisageable
t'exageres un tantinet ;-)
J'avais donc fini par opter pour un cpio qui est largement plus portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
euh... toto.cpio plutot ;-)
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
C'est des unix ca ? ;-)
Etienne de Tocqueville
JustMe a écrit sur fr.comp.os.unix :
et l'option "--files-from" de tar elle est la pour quoi ? ;-) Ben en fait, ces options à double "-" n'existe partiquement sur aucun
des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus délicats sur les autres unix, et principalement sur AIX...
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour dire, certains arguments ont meme l'effet strictement inverse d'un unix à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option n'est pas envisageable
t'exageres un tantinet ;-)
Non non, la commande "tar" est bien la plus incopatible que je connaisse. Il y a peu d'arguments en commun. Comparativement, "ls" st bien plus portable.
J'avais donc fini par opter pour un cpio qui est largement plus portable : ls | cpio -o -H ustar toto.tar Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et non les fichiers qu'ils contiennent. J'avais donc plutot du faire : find . -type f | cpio -o -H ustar toto.tar
euh... toto.cpio plutot ;-)
Non, toto.tar. Ca génère bien un fichier "tar", que j'exploite d'ailleurs avec la commande "tar" et pas avec "cpio -i". L'argument -H est là pour ça.
Sinon, bien sur, il manquait un ">" avant toto.tar : j'ai tapé la commande de tete sans vérifier.
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
C'est des unix ca ? ;-)
Oui, bien sur ! Et probablement les plus répandus. Pourquoi cette question ?
JustMe <pasdesp@m.merci> a écrit sur fr.comp.os.unix :
et l'option "--files-from" de tar elle est la pour quoi ? ;-)
Ben en fait, ces options à double "-" n'existe partiquement sur aucun
des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus
délicats sur les autres unix, et principalement sur AIX...
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour
dire, certains arguments ont meme l'effet strictement inverse d'un unix
à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option
n'est pas envisageable
t'exageres un tantinet ;-)
Non non, la commande "tar" est bien la plus incopatible que je
connaisse. Il y a peu d'arguments en commun. Comparativement, "ls" st
bien plus portable.
J'avais donc fini par opter pour un cpio qui est largement plus
portable :
ls | cpio -o -H ustar toto.tar
Le seul hic, c'est que contrairement au "tar", ça tar les répertoires
et
non les fichiers qu'ils contiennent. J'avais donc plutot du faire :
find . -type f | cpio -o -H ustar toto.tar
euh... toto.cpio plutot ;-)
Non, toto.tar. Ca génère bien un fichier "tar", que j'exploite
d'ailleurs avec la commande "tar" et pas avec "cpio -i". L'argument -H
est là pour ça.
Sinon, bien sur, il manquait un ">" avant toto.tar : j'ai tapé la
commande de tete sans vérifier.
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
C'est des unix ca ? ;-)
Oui, bien sur ! Et probablement les plus répandus. Pourquoi cette
question ?
et l'option "--files-from" de tar elle est la pour quoi ? ;-) Ben en fait, ces options à double "-" n'existe partiquement sur aucun
des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus délicats sur les autres unix, et principalement sur AIX...
commande la plus incompatible d'un unix à l'autre que je connaisse. Pour dire, certains arguments ont meme l'effet strictement inverse d'un unix à l'autre ! Bref, comme je fais des scripts portables, ce genre d'option n'est pas envisageable
t'exageres un tantinet ;-)
Non non, la commande "tar" est bien la plus incopatible que je connaisse. Il y a peu d'arguments en commun. Comparativement, "ls" st bien plus portable.
J'avais donc fini par opter pour un cpio qui est largement plus portable : ls | cpio -o -H ustar toto.tar Le seul hic, c'est que contrairement au "tar", ça tar les répertoires et non les fichiers qu'ils contiennent. J'avais donc plutot du faire : find . -type f | cpio -o -H ustar toto.tar
euh... toto.cpio plutot ;-)
Non, toto.tar. Ca génère bien un fichier "tar", que j'exploite d'ailleurs avec la commande "tar" et pas avec "cpio -i". L'argument -H est là pour ça.
Sinon, bien sur, il manquait un ">" avant toto.tar : j'ai tapé la commande de tete sans vérifier.
Ca marche sur Solaris, IRIX, HPUX, AIX, donc ça m'allait :-)
C'est des unix ca ? ;-)
Oui, bien sur ! Et probablement les plus répandus. Pourquoi cette question ?
Regis ARCHAMBAULT
Le Sat, 24 Apr 2004 01:21:55 +0200, Etienne de Tocqueville a écrit:
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus délicats sur les autres unix, et principalement sur AIX...
Le Sat, 24 Apr 2004 01:21:55 +0200, Etienne nous disait:
Ben en fait, ces options à double "-" n'existe partiquement sur aucun des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus délicats sur les autres unix, et principalement sur AIX...
Tu as des exemples ? Ça m'intéresse. Enfin pour ma prt, je n'ai jamais été root sur AIX, mais en simple user sur un 4.3, je n'au jamais eu de mal à compiler les GNU fileutils, vim, slrn ...
-- Tinou
Le Sat, 24 Apr 2004 01:21:55 +0200, Etienne nous disait:
Ben en fait, ces options à double "-" n'existe partiquement sur aucun
des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus
délicats sur les autres unix, et principalement sur AIX...
Tu as des exemples ? Ça m'intéresse. Enfin pour ma prt, je n'ai jamais
été root sur AIX, mais en simple user sur un 4.3, je n'au jamais eu de
mal à compiler les GNU fileutils, vim, slrn ...
Le Sat, 24 Apr 2004 01:21:55 +0200, Etienne nous disait:
Ben en fait, ces options à double "-" n'existe partiquement sur aucun des unix que je fréquente ! Par ailleurs, "tar" est probablement la
les outils gnu compilent partout ;-)
Ils compilent très bien sur Solaris, mais c'est généralement plus délicats sur les autres unix, et principalement sur AIX...
Tu as des exemples ? Ça m'intéresse. Enfin pour ma prt, je n'ai jamais été root sur AIX, mais en simple user sur un 4.3, je n'au jamais eu de mal à compiler les GNU fileutils, vim, slrn ...
-- Tinou
Stephane Chazelas
2004-04-23, 15:15(+02), Remi Moyen:
En faisant le ménage sur une machine, je tombe sur un répértoire de logs qui contient beaucoup de fichiers, tous inutiles. Après vérification, je fais donc un brutal rm. Et là...
$ rm * bash: /bin/rm: Argument list too long
Pourquoi utiliser bash ? C'est completement dépassé comme shell.
Avec zsh:
zmodload zsh/files rm ./*
(avec le module "files" chargé, rm devient un builtin, il n'y a donc plus la limitation du execve(2)).
Ou encore:
autoload -U zargs zargs ./* -- rm
Avec ksh93 (dont je ne recommande pas l'usage, par contre):
command -x rm ./*
Sinon, avec la plupart des finds (sauf celui de GNU, auquel cas on passera par print0/xargs -0):
En faisant le ménage sur une machine, je tombe sur un répértoire de logs
qui contient beaucoup de fichiers, tous inutiles. Après vérification, je
fais donc un brutal rm. Et là...
$ rm *
bash: /bin/rm: Argument list too long
Pourquoi utiliser bash ? C'est completement dépassé comme shell.
Avec zsh:
zmodload zsh/files
rm ./*
(avec le module "files" chargé, rm devient un builtin, il n'y a
donc plus la limitation du execve(2)).
Ou encore:
autoload -U zargs
zargs ./* -- rm
Avec ksh93 (dont je ne recommande pas l'usage, par contre):
command -x rm ./*
Sinon, avec la plupart des finds (sauf celui de GNU, auquel cas
on passera par print0/xargs -0):
En faisant le ménage sur une machine, je tombe sur un répértoire de logs qui contient beaucoup de fichiers, tous inutiles. Après vérification, je fais donc un brutal rm. Et là...
$ rm * bash: /bin/rm: Argument list too long
Pourquoi utiliser bash ? C'est completement dépassé comme shell.
Avec zsh:
zmodload zsh/files rm ./*
(avec le module "files" chargé, rm devient un builtin, il n'y a donc plus la limitation du execve(2)).
Ou encore:
autoload -U zargs zargs ./* -- rm
Avec ksh93 (dont je ne recommande pas l'usage, par contre):
command -x rm ./*
Sinon, avec la plupart des finds (sauf celui de GNU, auquel cas on passera par print0/xargs -0):
Pourquoi utiliser bash ? C'est completement dépassé comme shell.
Oh oui, c'est sur ! C'est pour ça que je reste sous Windows ! Je n'ai pas le temps de suivre toutes ces évolutions sous unix...
Avec zsh:
J'ai du mal à comprendre l'utilité des solutions qui ne marche qu'avec les commandes gnu, mais celles qui ne marchent qu'avec un shell donné m'étonnent encore plus ! ;-)
Pour moi, une solution marche sur tous les OS, avec tous les shell, sinon ça n'est pas une solution, mais un contournement. Sauf bien sur si la question concerne un shell spécifique, mais ça n'était pas le cas ici.
Mais bon, c'est peut-etre une déformation professionelle due au fait que tout ce que je fais doit marcher sur les 4 OS qui sont utilisés dans la boite, et ne doit donc utiliser que des commandes marchant sous /bin/sh de base...
Stephane Chazelas <cette.adresse@est.invalid> a écrit sur fr.comp.os.unix :
$ rm *
bash: /bin/rm: Argument list too long
Pourquoi utiliser bash ? C'est completement dépassé comme shell.
Oh oui, c'est sur ! C'est pour ça que je reste sous Windows ! Je n'ai
pas le temps de suivre toutes ces évolutions sous unix...
Avec zsh:
J'ai du mal à comprendre l'utilité des solutions qui ne marche qu'avec
les commandes gnu, mais celles qui ne marchent qu'avec un shell donné
m'étonnent encore plus ! ;-)
Pour moi, une solution marche sur tous les OS, avec tous les shell,
sinon ça n'est pas une solution, mais un contournement. Sauf bien sur si
la question concerne un shell spécifique, mais ça n'était pas le cas ici.
Mais bon, c'est peut-etre une déformation professionelle due au fait que
tout ce que je fais doit marcher sur les 4 OS qui sont utilisés dans la
boite, et ne doit donc utiliser que des commandes marchant sous /bin/sh
de base...
Pourquoi utiliser bash ? C'est completement dépassé comme shell.
Oh oui, c'est sur ! C'est pour ça que je reste sous Windows ! Je n'ai pas le temps de suivre toutes ces évolutions sous unix...
Avec zsh:
J'ai du mal à comprendre l'utilité des solutions qui ne marche qu'avec les commandes gnu, mais celles qui ne marchent qu'avec un shell donné m'étonnent encore plus ! ;-)
Pour moi, une solution marche sur tous les OS, avec tous les shell, sinon ça n'est pas une solution, mais un contournement. Sauf bien sur si la question concerne un shell spécifique, mais ça n'était pas le cas ici.
Mais bon, c'est peut-etre une déformation professionelle due au fait que tout ce que je fais doit marcher sur les 4 OS qui sont utilisés dans la boite, et ne doit donc utiliser que des commandes marchant sous /bin/sh de base...
