rm ne fonctionne pas si il y a trop de fichier ???
17 réponses
Eric Belhomme
j'ai un soucis avec la commande rm :
# rm -f ./*
bash: /bin/rm: Argument list too long
le repertoire en question contient plus de 12000 fichiers... et la commande
s'execute parfaitement lorsqu'il n'y a que quelques dizaines de fichiers...
Quelqu'un a une explication, et un moyen de contourner le pb ?
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
On Tue, 22 Jul 2003 02:48:39 +0200, Christophe Le Gal wrote:
Hein ?!? Elle est pas minime du tout : avec sa commande (s'il n'y avait pas trop de fichiers) on efface le contenu du repertoire courant. Avec la tienne on efface le contenu de /
Ca m'etonnerait qu'il veuille faire ca.
Présisément, c'est ce que j'écris à la fin de mon courrier.
nicolas patrois : pts noir asocial -- PEACE
M : La guerre, ça amène la mort, les épidémie, la vermine... la souffrance, la destruction, la peur... P : ...Et les pacifistes !
On Tue, 22 Jul 2003 02:48:39 +0200, Christophe Le Gal wrote:
Hein ?!?
Elle est pas minime du tout :
avec sa commande (s'il n'y avait pas trop de fichiers) on efface le
contenu du repertoire courant.
Avec la tienne on efface le contenu de /
Ca m'etonnerait qu'il veuille faire ca.
Présisément, c'est ce que j'écris à la fin de mon courrier.
nicolas patrois : pts noir asocial
--
PEACE
M : La guerre, ça amène la mort, les épidémie, la vermine... la souffrance, la destruction, la peur...
P : ...Et les pacifistes !
On Tue, 22 Jul 2003 02:48:39 +0200, Christophe Le Gal wrote:
Hein ?!? Elle est pas minime du tout : avec sa commande (s'il n'y avait pas trop de fichiers) on efface le contenu du repertoire courant. Avec la tienne on efface le contenu de /
Ca m'etonnerait qu'il veuille faire ca.
Présisément, c'est ce que j'écris à la fin de mon courrier.
nicolas patrois : pts noir asocial -- PEACE
M : La guerre, ça amène la mort, les épidémie, la vermine... la souffrance, la destruction, la peur... P : ...Et les pacifistes !
Eric Belhomme
Christophe Le Gal wrote in news::
Si on veut en plus faire ca proprement, on peut : find -type f -maxdepth 1 | xargs rm -f
merci, j'ai pu adapter ca a mes besoins ;)
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Christophe Le Gal <christophe-n2@vinigou.org> wrote in
news:slrnbhp3ek.17a.christophe-n2@linux.local:
Si on veut en plus faire ca proprement, on peut :
find -type f -maxdepth 1 | xargs rm -f
merci, j'ai pu adapter ca a mes besoins ;)
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
Si on veut en plus faire ca proprement, on peut : find -type f -maxdepth 1 | xargs rm -f
merci, j'ai pu adapter ca a mes besoins ;)
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Bernard Déléchamp
Christophe Le Gal wrote:
Maintenant, s'il y a des répertoires là-dedans, ou des fichiers avec des caractères exotiques ou des espaces... A moins, bien sûr que la commande echo n'ait une limitation elle-aussi.
Vu que la limitation est pour tout le monde, je ne vois pas bien ce que ca change.
Pas tout à fait :
[ root]# find /usr -type f |wc 150838 151390 7315405 [ root]# ls $(find /usr -type f) >/dev/null -bash: /bin/ls: Argument list too long [ root]# /bin/echo $(find /usr -type f) >/dev/null -bash: /bin/echo: Argument list too long [ root]# echo $(find /usr -type f) >/dev/null [ root]#
cette commande echo (builtin shell) accepte donc plus de caractères dans ses arguments que ls ou que /bin/echo. La limitation n'est donc pas la même pour tout le monde. Ce qui n'enlève rien à la pertinence de ta proposition. Quant à dire si echo * est plus ou moins rapide que ls...
Cordialement.
-- Quand Marilou danse reggae Ouvrir braguette et prodiguer Salutations distinguées De petit serpent katangais Serge Gainsbourg.
Christophe Le Gal wrote:
Maintenant, s'il y a des répertoires là-dedans, ou des fichiers avec des
caractères exotiques ou des espaces... A moins, bien sûr que la commande
echo n'ait une limitation elle-aussi.
Vu que la limitation est pour tout le monde, je ne vois pas bien ce que
ca change.
Pas tout à fait :
[root@mangouin01430 root]# find /usr -type f |wc
150838 151390 7315405
[root@mangouin01430 root]# ls $(find /usr -type f) >/dev/null
-bash: /bin/ls: Argument list too long
[root@mangouin01430 root]# /bin/echo $(find /usr -type f) >/dev/null
-bash: /bin/echo: Argument list too long
[root@mangouin01430 root]# echo $(find /usr -type f) >/dev/null
[root@mangouin01430 root]#
cette commande echo (builtin shell) accepte donc plus de caractères dans
ses arguments que ls ou que /bin/echo. La limitation n'est donc pas la
même pour tout le monde. Ce qui n'enlève rien à la pertinence de ta
proposition. Quant à dire si echo * est plus ou moins rapide que ls...
Cordialement.
--
Quand Marilou danse reggae
Ouvrir braguette et prodiguer
Salutations distinguées
De petit serpent katangais Serge Gainsbourg.
Maintenant, s'il y a des répertoires là-dedans, ou des fichiers avec des caractères exotiques ou des espaces... A moins, bien sûr que la commande echo n'ait une limitation elle-aussi.
Vu que la limitation est pour tout le monde, je ne vois pas bien ce que ca change.
Pas tout à fait :
[ root]# find /usr -type f |wc 150838 151390 7315405 [ root]# ls $(find /usr -type f) >/dev/null -bash: /bin/ls: Argument list too long [ root]# /bin/echo $(find /usr -type f) >/dev/null -bash: /bin/echo: Argument list too long [ root]# echo $(find /usr -type f) >/dev/null [ root]#
cette commande echo (builtin shell) accepte donc plus de caractères dans ses arguments que ls ou que /bin/echo. La limitation n'est donc pas la même pour tout le monde. Ce qui n'enlève rien à la pertinence de ta proposition. Quant à dire si echo * est plus ou moins rapide que ls...
Cordialement.
-- Quand Marilou danse reggae Ouvrir braguette et prodiguer Salutations distinguées De petit serpent katangais Serge Gainsbourg.
Christophe Le Gal
In article <bfmcgk$8be$, Bernard Déléchamp wrote:
Christophe Le Gal wrote:
Vu que la limitation est pour tout le monde, je ne vois pas bien ce que ca change.
Pas tout à fait :
cette commande echo (builtin shell) accepte donc plus de caractères dans
Exact. echo est une commande interne du shell, et n'est donc pas concerne par la limitation de la taille de la liste d'arguments. dont acte.
De plus il faut preciser que certaines configs font de ls un alias sur ls --color Dans ce cas donner le resultat a xargs rm ne sera pas du plus bel effet. Un argument de plus en faveur du find -maxdepth que j'ai propose plus loin donc.
Par contre, je n'aime toujours pas le echo, builtin ou pas, parce que ca annule un peu l'itneret du pipe. Meme s'il n'y a pas de limitation de la taille de la liste d'arguments (ou si la limitation n'est pas la meme), il y a quand meme construction d'une liste, ou d'une chaine. Si cette liste est tres grande (et c'est apparament le cas), ca n'est pas tres ethetique de construire une grande liste avant de commencer le boulot dessus alors que le travail pouvait etre fait a la chaine.
Vu que echo est un builtin du shell, on pourrait imaginer que le shell pourrait etre assez malin pour commencer a donner le resultat au consommateur avant d'avoir fini. Mais ce n'est pas le cas.
Cordialement. -- Christophe Le Gal
In article <bfmcgk$8be$1@mangouin01430.delechamp.fam>, Bernard Déléchamp wrote:
Christophe Le Gal wrote:
Vu que la limitation est pour tout le monde, je ne vois pas bien ce que
ca change.
Pas tout à fait :
cette commande echo (builtin shell) accepte donc plus de caractères dans
Exact. echo est une commande interne du shell, et n'est donc pas
concerne par la limitation de la taille de la liste d'arguments. dont acte.
De plus il faut preciser que certaines configs font de ls un alias
sur
ls --color
Dans ce cas donner le resultat a xargs rm ne sera pas du plus bel effet.
Un argument de plus en faveur du find -maxdepth que j'ai propose plus loin
donc.
Par contre, je n'aime toujours pas le echo, builtin ou pas, parce que
ca annule un peu l'itneret du pipe. Meme s'il n'y a pas de limitation de la
taille de la liste d'arguments (ou si la limitation n'est pas la meme), il y
a quand meme construction d'une liste, ou d'une chaine.
Si cette liste est tres grande (et c'est apparament le cas), ca n'est
pas tres ethetique de construire une grande liste avant de commencer
le boulot dessus alors que le travail pouvait etre fait a la chaine.
Vu que echo est un builtin du shell, on pourrait imaginer que le shell
pourrait etre assez malin pour commencer a donner le resultat au
consommateur avant d'avoir fini. Mais ce n'est pas le cas.
Vu que la limitation est pour tout le monde, je ne vois pas bien ce que ca change.
Pas tout à fait :
cette commande echo (builtin shell) accepte donc plus de caractères dans
Exact. echo est une commande interne du shell, et n'est donc pas concerne par la limitation de la taille de la liste d'arguments. dont acte.
De plus il faut preciser que certaines configs font de ls un alias sur ls --color Dans ce cas donner le resultat a xargs rm ne sera pas du plus bel effet. Un argument de plus en faveur du find -maxdepth que j'ai propose plus loin donc.
Par contre, je n'aime toujours pas le echo, builtin ou pas, parce que ca annule un peu l'itneret du pipe. Meme s'il n'y a pas de limitation de la taille de la liste d'arguments (ou si la limitation n'est pas la meme), il y a quand meme construction d'une liste, ou d'une chaine. Si cette liste est tres grande (et c'est apparament le cas), ca n'est pas tres ethetique de construire une grande liste avant de commencer le boulot dessus alors que le travail pouvait etre fait a la chaine.
Vu que echo est un builtin du shell, on pourrait imaginer que le shell pourrait etre assez malin pour commencer a donner le resultat au consommateur avant d'avoir fini. Mais ce n'est pas le cas.
Cordialement. -- Christophe Le Gal
Bernard Déléchamp
Christophe Le Gal wrote:
De plus il faut preciser que certaines configs font de ls un alias sur ls --color Dans ce cas donner le resultat a xargs rm ne sera pas du plus bel effet.
ou utiliser /bin/ls pour s'affranchir des aliases éventuels.
-- Le problème avec les gens intelligents, c'est qu'ils ne sont jamais assez intelligents pour ne pas dire qu'ils sont les plus intelligents. Boris Vian
Christophe Le Gal wrote:
De plus il faut preciser que certaines configs font de ls un alias
sur
ls --color
Dans ce cas donner le resultat a xargs rm ne sera pas du plus bel effet.
ou utiliser /bin/ls pour s'affranchir des aliases éventuels.
--
Le problème avec les gens intelligents, c'est qu'ils ne sont jamais
assez intelligents pour ne pas dire qu'ils sont les plus intelligents.
Boris Vian
De plus il faut preciser que certaines configs font de ls un alias sur ls --color Dans ce cas donner le resultat a xargs rm ne sera pas du plus bel effet.
ou utiliser /bin/ls pour s'affranchir des aliases éventuels.
-- Le problème avec les gens intelligents, c'est qu'ils ne sont jamais assez intelligents pour ne pas dire qu'ils sont les plus intelligents. Boris Vian
Christophe Le Gal
la commande interne du shell ouvre une paire de pipes, forke et ensuite lance la commande find et redirige son output. La commande "echo" lancee est en fait lancee comme si tu ecrivait: find /usr -type f | tr -d 'n' > /dev/null Le shell, bash tout au moins, essaye de faire les choses au plus simple...
Pas avec mon bash en tous cas. Lorsque je fais echo $(a) | b, quelque soit la duree de la commande a, elle est totalement executee avant que le moindre octet ne soit donne en entree de la commande b. La sortie de a est donc bien stockee qq part. Pas dans une liste d'arguments, comme tout le monde l'a dit, puisque echo n'est pas un programme, mais qq part dans une variable (peut etre simplement un buffer, mais alors il est gros) du shell. Alors que, bien entendu, l'interet de a | b c'est justement que ca ne se passe pas comme ca.
-- Christophe Le Gal
la commande interne du shell ouvre une paire de pipes,
forke et ensuite lance la commande find et redirige son output.
La commande "echo" lancee est en fait lancee comme si tu ecrivait:
find /usr -type f | tr -d 'n' > /dev/null
Le shell, bash tout au moins, essaye de faire les choses au plus
simple...
Pas avec mon bash en tous cas.
Lorsque je fais echo $(a) | b, quelque soit la duree de la commande a,
elle est totalement executee avant que le moindre octet ne soit
donne en entree de la commande b. La sortie de a est donc bien
stockee qq part. Pas dans une liste d'arguments, comme tout le monde
l'a dit, puisque echo n'est pas un programme, mais qq part dans une
variable (peut etre simplement un buffer, mais alors il est gros) du
shell.
Alors que, bien entendu, l'interet de a | b c'est justement que ca ne
se passe pas comme ca.
la commande interne du shell ouvre une paire de pipes, forke et ensuite lance la commande find et redirige son output. La commande "echo" lancee est en fait lancee comme si tu ecrivait: find /usr -type f | tr -d 'n' > /dev/null Le shell, bash tout au moins, essaye de faire les choses au plus simple...
Pas avec mon bash en tous cas. Lorsque je fais echo $(a) | b, quelque soit la duree de la commande a, elle est totalement executee avant que le moindre octet ne soit donne en entree de la commande b. La sortie de a est donc bien stockee qq part. Pas dans une liste d'arguments, comme tout le monde l'a dit, puisque echo n'est pas un programme, mais qq part dans une variable (peut etre simplement un buffer, mais alors il est gros) du shell. Alors que, bien entendu, l'interet de a | b c'est justement que ca ne se passe pas comme ca.
-- Christophe Le Gal
J. Mayer
On Thu, 24 Jul 2003 09:35:25 +0000, Christophe Le Gal wrote:
la commande interne du shell ouvre une paire de pipes, forke et ensuite lance la commande find et redirige son output. La commande "echo" lancee est en fait lancee comme si tu ecrivait: find /usr -type f | tr -d 'n' > /dev/null Le shell, bash tout au moins, essaye de faire les choses au plus simple...
Pas avec mon bash en tous cas. Lorsque je fais echo $(a) | b, quelque soit la duree de la commande a, elle est totalement executee avant que le moindre octet ne soit donne en entree de la commande b. La sortie de a est donc bien stockee qq part. Pas dans une liste d'arguments, comme tout le monde l'a dit, puisque echo n'est pas un programme, mais qq part dans une variable (peut etre simplement un buffer, mais alors il est gros) du shell. Alors que, bien entendu, l'interet de a | b c'est justement que ca ne se passe pas comme ca. Oui, c'est vrai.
Je pense que c'est bufferise dans un buffer dynamique, donc qui fait... la taille qu'il faut... Ca ne peut pas etre dans une variable, puisque le shell ne peut pas se permettre de modifier l'environnement sans demande (au minimum implicite) de l'utilisateur. Il faudrait verifier dans POSIX (j'ai la flemme pour l'instant), mais je pense que si Bash se comporte comme ca, c'est parce que la norme dit que la commande 'a' doit etre executee totalement pour pouvoir exploiter son resultat, sans doute a cause des effets de bords possibles si 'a' est une commande complexe.
Cordialement.
J. Mayer
On Thu, 24 Jul 2003 09:35:25 +0000, Christophe Le Gal wrote:
la commande interne du shell ouvre une paire de pipes,
forke et ensuite lance la commande find et redirige son output.
La commande "echo" lancee est en fait lancee comme si tu ecrivait:
find /usr -type f | tr -d 'n' > /dev/null
Le shell, bash tout au moins, essaye de faire les choses au plus
simple...
Pas avec mon bash en tous cas.
Lorsque je fais echo $(a) | b, quelque soit la duree de la commande a,
elle est totalement executee avant que le moindre octet ne soit
donne en entree de la commande b. La sortie de a est donc bien
stockee qq part. Pas dans une liste d'arguments, comme tout le monde
l'a dit, puisque echo n'est pas un programme, mais qq part dans une
variable (peut etre simplement un buffer, mais alors il est gros) du
shell.
Alors que, bien entendu, l'interet de a | b c'est justement que ca ne
se passe pas comme ca.
Oui, c'est vrai.
Je pense que c'est bufferise dans un buffer dynamique,
donc qui fait... la taille qu'il faut...
Ca ne peut pas etre dans une variable, puisque le shell ne peut
pas se permettre de modifier l'environnement sans demande
(au minimum implicite) de l'utilisateur. Il faudrait verifier
dans POSIX (j'ai la flemme pour l'instant), mais je pense
que si Bash se comporte comme ca, c'est parce que la norme
dit que la commande 'a' doit etre executee totalement pour pouvoir
exploiter son resultat, sans doute a cause des effets de bords
possibles si 'a' est une commande complexe.
On Thu, 24 Jul 2003 09:35:25 +0000, Christophe Le Gal wrote:
la commande interne du shell ouvre une paire de pipes, forke et ensuite lance la commande find et redirige son output. La commande "echo" lancee est en fait lancee comme si tu ecrivait: find /usr -type f | tr -d 'n' > /dev/null Le shell, bash tout au moins, essaye de faire les choses au plus simple...
Pas avec mon bash en tous cas. Lorsque je fais echo $(a) | b, quelque soit la duree de la commande a, elle est totalement executee avant que le moindre octet ne soit donne en entree de la commande b. La sortie de a est donc bien stockee qq part. Pas dans une liste d'arguments, comme tout le monde l'a dit, puisque echo n'est pas un programme, mais qq part dans une variable (peut etre simplement un buffer, mais alors il est gros) du shell. Alors que, bien entendu, l'interet de a | b c'est justement que ca ne se passe pas comme ca. Oui, c'est vrai.
Je pense que c'est bufferise dans un buffer dynamique, donc qui fait... la taille qu'il faut... Ca ne peut pas etre dans une variable, puisque le shell ne peut pas se permettre de modifier l'environnement sans demande (au minimum implicite) de l'utilisateur. Il faudrait verifier dans POSIX (j'ai la flemme pour l'instant), mais je pense que si Bash se comporte comme ca, c'est parce que la norme dit que la commande 'a' doit etre executee totalement pour pouvoir exploiter son resultat, sans doute a cause des effets de bords possibles si 'a' est une commande complexe.
