xargs_for_idiots

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: Re: rm problem 
From: Joe Brenner <doom@kzsu.stanford.edu>
Date: Mon, 28 Aug 2000 17:24:30 -0700

Victor Shnayder <shnayder@cs.princeton.edu> wrote: 

> kevin@oceania.net wrote:
> > 
> > I have managed to runout of inodes on a partition du to a buggy routine.
> > 
> > I know what I want to delete, but when I do rm -f * in the problem
> > directory it comes back with "Argument list too long"
> > 
> > Can anyone think of a way around this one?
> 
> Either use xargs (man xargs), or just do rm -f a*;rm -f b*;rm -f
> c*......

Hm.  I guess this is supposed to work then? 

  ls | xargs rm

For some reason, the function of xargs will not sink into my
head... I suspect that it's man page is a good argument
against man pages in general, but I have to understand what
it does better before I can tell if I'm just being thick. 

Anyway, this would also do it: 

  cd <problem_area>
  find . -type f -exec rm {} \;

Note, this deletes all files recursively below the problem location.
If that's not the Right Thing, I guess you'd need to play
with something like the -maxdepth option.

===

Subject: Re: rm problem
From: Alan Shutko <ats@acm.org>
Date: 28 Aug 2000 20:38:39 -0400

Joe Brenner <doom@kzsu.stanford.edu> writes:

> For some reason, the function of xargs will not sink into my
> head... 

What xargs does is take a list of things on standard input (usually
files) and run the command specified, putting as many of those files
(or whatever) on each command line, until the command has been run for
each file.

So, if you had a directory of ten thousand files, not all of them
might fit on the command line (I think it's a kernel limit or
something).  xargs knows how long the command line limit is, and will
take the first 50 (for instance) and run rm once, take the next 50 and
run rm again, and so on, until rm has been run on all the files.

This is different from find because it doesn't exec rm once for each
file, so it should be as efficient as possible.  (That's the theory,
at least.)

In general, you'd run into the "Argument list too long" more on other
unices, since Linux has a healthy limit.

xargs with the -0 option can also be useful when you have a list of
files with spaces in the name.

===

Subject: Re: rm problem 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Tue, 29 Aug 2000 09:40:50 +0800

I have managed to runout of inodes on a partition du to a buggy routine.
> 
> I know what I want to delete, but when I do rm -f * in the problem
> directory it comes back with "Argument list too long"
> 
> Can anyone think of a way around this one?

dir | xargs --max-lines=300 rm -f

or some such.

===

Subject: Re: rm problem 
From: Joe Brenner <doom@kzsu.stanford.edu>
Date: Mon, 28 Aug 2000 20:07:32 -0700

Alan Shutko <ats@acm.org> wrote: 

> Joe Brenner <doom@kzsu.stanford.edu> writes:
> 
> > For some reason, the function of xargs will not sink into my
> > head... 
> 
> What xargs does is take a list of things on standard input (usually
> files) and run the command specified, putting as many of those files
> (or whatever) on each command line, until the command has been run for
> each file.

I guess what bothers me most is that there doesn't seem to
be any placeholder for where the filename is going to go.
Like what if you don't want the filename at the end of the
command line?  Then you revert back to find with -exec?

===

Subject: Re: rm problem
From: Aaron Schrab <aaron+rawhide@schrab.com>
Date: Mon, 28 Aug 2000 22:28:56 -0500


At 20:07 -0700 28 Aug 2000, Joe Brenner <doom@kzsu.stanford.edu> wrote:
> I guess what bothers me most is that there doesn't seem to
> be any placeholder for where the filename is going to go.
> Like what if you don't want the filename at the end of the
> command line?  Then you revert back to find with -exec?

xargs does have support for a place holder.  The default is even the
same as for find -exec:

       --replace[=replace-str], -i[replace-str]
              Replace occurences of replace-str  in  the  initial
              arguments  with  names  read  from  standard input.
              Also, unquoted blanks do not  terminate  arguments.
              If  replace-str  is  omitted,  it  defaults to "{}"
              (like for `find -exec').  Implies -x and -l 1.

===

Subject: Re: rm problem
From: "Mike A. Harris" <mharris@meteng.on.ca>
Date: Tue, 29 Aug 2000 00:47:17 -0400 (EDT)


On Tue, 29 Aug 2000 kevin@oceania.net wrote:

>I have managed to runout of inodes on a partition du to a buggy routine.
>
>I know what I want to delete, but when I do rm -f * in the problem
>directory it comes back with "Argument list too long"
>
>Can anyone think of a way around this one?

Use this instead:

ls | xargs rm -f

Or if you want to do "rm -rf *" use:

find . | xargs rm -f

TTYL

===

Subject: Re: rm problem 
From: "Mike A. Harris" <mharris@meteng.on.ca>
Date: Tue, 29 Aug 2000 00:55:51 -0400 (EDT)


On Mon, 28 Aug 2000, Joe Brenner wrote:

>Date: Mon, 28 Aug 2000 20:07:32 -0700
>From: Joe Brenner <doom@kzsu.stanford.edu>
>To: redhat-devel-list@redhat.com
>Subject: Re: rm problem 
>
>
>Alan Shutko <ats@acm.org> wrote: 
>
>> Joe Brenner <doom@kzsu.stanford.edu> writes:
>> 
>> > For some reason, the function of xargs will not sink into my
>> > head... 
>> 
>> What xargs does is take a list of things on standard input (usually
>> files) and run the command specified, putting as many of those files
>> (or whatever) on each command line, until the command has been run for
>> each file.
>
>I guess what bothers me most is that there doesn't seem to
>be any placeholder for where the filename is going to go.
>Like what if you don't want the filename at the end of the
>command line?  Then you revert back to find with -exec?

man xargs

...

       --replace[=replace-str], -i[replace-str]
              Replace occurences of replace-str  in  the  initial
              arguments  with  names  read  from  standard input.
              Also, unquoted blanks do not  terminate  arguments.
              If  replace-str  is  omitted,  it  defaults to "{}"
              (like for `find -exec').  Implies -x and -l 1.



===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu