🚀 go-pugleaf

In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:
>
>                    Piping filenames to the rm command???
>
>I am trying to write a script to uninstall files installed via an
>ninstall package.  I can generate a list of filenames to delete, but
>I haven't figured out how to pipe this list of names to rm.  Here's
>the heart of my script so far, followed by its output:
>
>    ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4

 What is wrong with:

    rm `ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4`

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

Thanks to all who emailed me the solution to this problem!  For the 
benefit of anyone who might be curious, here's one answer:

ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 | xargs rm
                                                         ^^^^^^^^^^
The xargs utility passes the input lines to the rm command as
parameters--just what I was after.  Thanks again!

--Mike

#############################
# Mike Greiner              #
# Information Technology    #
# Hewlett-Packard           #
# Colorado Springs Division #
# greiner@col.hp.com        #
#############################

In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:
>
>                    Piping filenames to the rm command???
>
>I haven't figured out how to pipe this list of names to rm. 

You don't need to.  Pipe the list of names to  xargs rm.


>    ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4

Just change this to:

     ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 | xargs rm

This, of course, assumes you have xargs.  If you don't, you can get one 
of the PD versions that have been posted to c.s.u in the past.

Otherwise, if you know that the length of the list is relatively short (i.e.
it wont overrun the command line buffer length) you can do the following:

     rm `ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4`

else you could do the following:

     ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 | while read name
     do
         rm $name
     done

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

greiner@col.hp.com (Mike Greiner) writes:


>                    Piping filenames to the rm command???

>    ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4

>There may be a pretty simple solution to this, but I haven't found it.  I'm
>considering using a for-loop that parses each line as the loop counter, 
>but don't know if that's the best approach...appreciate any suggestions!

If you're sure the output of the ninstall does not exceed the limit of
what the shell you're using can handle (Bourne shell usually 5Kbytes),
you can use the following approach:

	ninstall .... | xargs rm

However, if the filelist from ninstall et al. does exceed the shell buffer
limit you can do something like (assuming Bourne shell):

	ninstall |
	while read filename
	do
		rm $filename
	done

					Kim Chr. Madsen

In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:
>
>                    Piping filenames to the rm command???
>There may be a pretty simple solution to this, but I haven't found it.  I'm
>considering using a for-loop that parses each line as the loop counter, 
>but don't know if that's the best approach...appreciate any suggestions!

See xargs. (if you have it on your system.)

Example of how it works:

find / -name 'core' -print | xargs rm

Dylan.
-- 
Matthew J Farwell                 | Email: dylan@ibmpcug.co.uk
The IBM PC User Group, PO Box 360,|        ...!uunet!ukc!ibmpcug!dylan
Harrow HA1 4LQ England            | CONNECT - Usenet Access in the UK!!
Phone: +44 81-863-1191            | Sun? Don't they make coffee machines?

In article <1990Sep28.211655.4903@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:
>>
>>    ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4
>
> What is wrong with:
>
>    rm `ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4`

The fact that you are limited in the number of files and cumulative length of
the names of the files.  If you come up with one extra name, or one too many
characters in the names, the shell will refuse to exec it, saying something
about "arg list too long".


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

In article <1990Sep29.001151.11544@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
>
>If you're sure the output of the ninstall does not exceed the limit of
>what the shell you're using can handle (Bourne shell usually 5Kbytes),
>you can use the following approach:
>
>	ninstall .... | xargs rm

No.  xargs was specifically written to handle the argument count and length
limits for command executions.  What it will do is run the rm command
multiple times (each with the maximum number of arguments that do not
exceed the limitations).



-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:

| Now I want to pipe the output of this command into rm.  Here's the output:

  I think what you want is the xargs routine, which may not be available
on your system but is on most.

Example:
  find {{stuff here}} -print | xargs rm -f
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

In article <1977@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
>In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:
>> Now I want to pipe the output of this command into rm.  Here's the output:
>
>  I think what you want is the xargs routine, which may not be available
>on your system but is on most.
>
>Example:
>  find {{stuff here}} -print | xargs rm -f

Locally, we've hacked our "find" to handle:

	$ find . -name \*.old -rm

And "find" will do the unlink() itself.  It also has similar "-chown" and
"-chgrp".  It's much faster than running "rm" a zillion times..
-- 
- Matthew T. Day, Sanyo/Icon, mday@iconsys.icon.com || uunet!iconsys!mday

cpcahil@virtech.uucp (Conor P. Cahill) writes:

>In article <1990Sep28.211655.4903@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>>In article <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:
>>>
>>>    ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4
>>
>> What is wrong with:
>>
>>    rm `ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4`

>The fact that you are limited in the number of files and cumulative length of
>the names of the files.  If you come up with one extra name, or one too many
>characters in the names, the shell will refuse to exec it, saying something
>about "arg list too long".

Perhaps this:
	
	ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 > tmpfile
	split -50 tmpsplit tmpfile
	for i in tmpsplit??
	do
		rm `cat $i`
	done

OK, it's not a solution for very very very long argument lists !!


	Stefan

In article <1990Sep29.001151.11544@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
> If you're sure the output of the ninstall does not exceed the limit of
> what the shell you're using can handle...

> 	ninstall .... | xargs rm

> However, if the filelist from ninstall et al. does exceed the shell buffer...

	ninstall .... | xargs rm

xargs will split the commandline into chunks the shell will handle.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

peter@ficc.ferranti.com (Peter da Silva) writes:

>In article <1990Sep29.001151.11544@diku.dk> I wrote:
>> If you're sure the output of the ninstall does not exceed the limit of
>> what the shell you're using can handle...

>> 	ninstall .... | xargs rm

>> However, if the filelist from ninstall et al. does exceed the shell buffer...

>	ninstall .... | xargs rm

>xargs will split the commandline into chunks the shell will handle.

Sorry for the misunderstanding that I confused by saying that xargs is
limited by the shell buffer size... However, I have run across a version
of xargs that exactly does what it isn't supposed to do: take stdin in one
chunk and if it doesn't fit -- too bad.... And that's what triggered my
response, however the I suppose the remaining 99% of xargs will do the 
job nicely.

						Kim Chr. Madsen

From previous postings-

> >Example:
> >  find {{stuff here}} -print | xargs rm -f
  
> Locally, we've hacked our "find" to handle:
> 	$ find . -name \*.old -rm

Our `find' (SunOS) supports the `-exec' option, and I assume this would be
fairly common.  So, those of you without xargs, and who | a. can't,  b. don't
want to | hack `find' use it like this:

	find {{stuff here}} -exec rm -f {} \;

Why use `xargs' when you don't need to ?

-- 
George P. J. Turczynski,   Computer Systems Engineer. Highland Logic Pty Ltd.
ACSnet: george@highland.oz |^^^^^^^^^^^^^^^^^^^^^^^^| Suite 1, 348-354 Argyle St
Phone:  +61 48 683490      |  Witty remarks are as  | Moss Vale, NSW. 2577
Fax:    +61 48 683474      |  hard to come by as is | Australia.
---------------------------   space to put them !    ---------------------------

george@hls0.hls.oz (George Turczynski) writes:

>Our `find' (SunOS) supports the `-exec' option, and I assume this would be
>fairly common.  So, those of you without xargs, and who | a. can't,  b. don't
>want to | hack `find' use it like this:

>	find {{stuff here}} -exec rm -f {} \;

>Why use `xargs' when you don't need to ?

There are a lot of uses of xargs that are superior to using find with the
exec option. Find is *SLOW*, so if you have the names of files you want to
do something with in a file or pipe use xargs for performance.

Find is also complicated to use for non-trivial tasks, and the syntax  is
often confusing to non-wizards, so specialized shell-scripts or programs
are often more intuitive and faster to create and maintain.

All this is not to bash find(1), which is a wonderful, general tool, however
the multitude of UNIX tools gives you the choice of selecting the one,
most appropriate for your task and the one you're most familiar with.

						Kim Chr. Madsen

In article <941@hls0.hls.oz> george@hls0.hls.oz (George Turczynski) writes:
>	find {{stuff here}} -exec rm -f {} \;
>Why use `xargs' when you don't need to ?

Perhaps an order of magnitude difference in speed/efficiency?
Besides the original question didn't specifically use "find."

Paul Chamberlain | I do NOT represent IBM.     tif@doorstop, sc30661 at ausvm6
512/838-7008     | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif

In article <941@hls0.hls.oz> george@hls0.hls.oz (George Turczynski) writes:
>From previous postings-
>
>> >Example:
>> >  find {{stuff here}} -print | xargs rm -f
>  
>> Locally, we've hacked our "find" to handle:
>> 	$ find . -name \*.old -rm
>
>Our `find' (SunOS) supports the `-exec' option, and I assume this would be
>fairly common.  So, those of you without xargs, and who | a. can't,  b. don't
>want to | hack `find' use it like this:
>
>	find {{stuff here}} -exec rm -f {} \;
>
>Why use `xargs' when you don't need to ?

2 points.
1) The original posting wasn't about find, it was about another pipe which
produced filenames on stdout, so comments on xargs were required.

2) find / -exec rm -f {} \; spawns rm everytime it encounters a file
so its very slow and expensive, whereas xargs collects all the filenames
together, bundles them up into lines which won't exceed the system limit
and then spawns one job for all of those. Its much more environmentally
friendly.

Dylan.
-- 
Matthew J Farwell                 | Email: dylan@ibmpcug.co.uk
The IBM PC User Group, PO Box 360,|        ...!uunet!ukc!ibmpcug!dylan
Harrow HA1 4LQ England            | CONNECT - Usenet Access in the UK!!
Phone: +44 81-863-1191            | Sun? Don't they make coffee machines?

In article <941@hls0.hls.oz> george@hls0.hls.oz (George Turczynski) writes:
>	find {{stuff here}} -exec rm -f {} \;
>
>Why use `xargs' when you don't need to ?

Because it is *******MUCH******* faster (assuming you are going to exec the
command more than once or twice).

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

In article <941@hls0.hls.oz> george@hls0.hls.oz (George Turczynski) writes:
>From previous postings-
>
>> >Example:
>> >  find {{stuff here}} -print | xargs rm -f

...deleted examples and discourse

>Why use `xargs' when you don't need to ?

Because the -exec for find will run the rm on a file by file basis.
If you find many matches to the pattern you have the overhead and
system load generated by an exec of rm for each file found.  Using
xargs can reduce the number of execs quite a bit and so would be
useful where you expect lots of files found or on a system with
heavy 24 hour usage.  In other cases, you would certainly not need
it, as you note.

Bob McGowan  (standard disclaimer, these are my own ...)
Product Support, Wyse Technology, San Jose, CA
..!uunet!wyse!bob
bob@wyse.com

In article <1990Oct5.145825.9454@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
>george@hls0.hls.oz (George Turczynski) writes:
>
>>Why use `xargs' when you don't need to ?
>
>There are a lot of uses of xargs that are superior to using find with the
>exec option. Find is *SLOW*, so if you have the names of files you want to
>do something with in a file or pipe use xargs for performance.

Find, in itself, is not slow.  The exec of a new process (the rm in this
case) for every file found is *SLOW*.  Obviously, if you already have the
list of files you don't need to run find to get them again. 

>Find is also complicated to use for non-trivial tasks, and the syntax  is
>often confusing to non-wizards, so specialized shell-scripts or programs
>are often more intuitive and faster to create and maintain.

This is getting into a typical religous issue, so I won't say much in
response other than the fact that if someone knows enough about the system
to creat shell scripts and/or programs it behooves them to take an 
extra few minutes to learn find.

Find in itself is not complicated (just some name selection logic) and 
should be one of the tools that anyone writing shells is intimately aware
of.  (BTW - I am one of the people that believe you shouldn't be allowed
to write any shell scripts until you have made a complete pass through
sections 1 & 1m (or 8, depending upon your OS) AND you should repeat this
on a regular basis).

As an aside, most of the specialized shell scripts that you mentioned will
usually run a find as part of the script anyway.

>All this is not to bash find(1), which is a wonderful, general tool, however
>the multitude of UNIX tools gives you the choice of selecting the one,
>most appropriate for your task and the one you're most familiar with.

But to make the correct selection you should be aware of most, if not
all, of the tools available (nothing is better than an educated decision).


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

In <28790001@col.hp.com> greiner@col.hp.com (Mike Greiner) writes:

>                    Piping filenames to the rm command???

>I am trying to write a script to uninstall files installed via an
>ninstall package.  I can generate a list of filenames to delete, but
>I haven't figured out how to pipe this list of names to rm.  Here's
>the heart of my script so far, followed by its output:

>    ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4

>Now I want to pipe the output of this command into rm.  Here's the output:

>     /usr/local/doc/ninstall/UserGuide.mm
>     /usr/local/man/man1/ninstall.1
>     /usr/local/man/man1m/installd.1m

>There may be a pretty simple solution to this, but I haven't found it.  I'm
>considering using a for-loop that parses each line as the loop counter, 
>but don't know if that's the best approach...appreciate any suggestions!

Well, a couple simple ways that will work most everywhere...

 1)  rm -f `ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4`

 2)  ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 | sh rm -f

 3)  ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 | xargs rm -f

 4)  ninstall -h $1 -vvvvv -p $2 | grep path | cut -d " " -f4 | while read file
     ; do ; rm -f $file ; done


There are pitfalls with all.
	#1, #2, and #3 will all complain if there are no files to remove
	  if you don't use the "-f" flag.
	#1 will fail if there are too many files to delete, or the total size
	  of their pathnames is above a magic number.
	#3 requires xargs
	#2 and #4 are bourne shell specific.


Have fun!
	-Jeff
-- 
Jeff Beadles	jeff@onion.pdx.com

On 6 Oct 90 01:14:38 GMT, cpcahil@virtech.uucp (Conor P. Cahill) said:

> Find, in itself, is not slow.  The exec of a new process (the rm in this
> case) for every file found is *SLOW*.  Obviously, if you already have the
> list of files you don't need to run find to get them again. 

This is true, but compared to VMS process creation, it's lightening fast.
(All "VMS is better than UNIX remarks" can go to /dev/null or direct mail
to me).

James "A VMS programmer in a former life"
--
James Brister                                           brister@decwrl.dec.com
DEC Western Software Lab., Palo Alto, CA    {uunet,sun,pyramid}!decwrl!brister

cpcahil@virtech.uucp (Conor P. Cahill) writes:

>In article <1990Oct5.145825.9454@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
>>There are a lot of uses of xargs that are superior to using find with the
>>exec option. Find is *SLOW*, so if you have the names of files you want to
>>do something with in a file or pipe use xargs for performance.

>Find, in itself, is not slow.  The exec of a new process (the rm in this
>case) for every file found is *SLOW*.  Obviously, if you already have the
>list of files you don't need to run find to get them again. 

Maybe not on your system, but on my system (a SYSV) system, find perfoms
a getpwd(3C) each time it enters a directory, and getpwd(3) is by
standard implemented by forking a shell to do a pwd(1) in oorder to
get the result ... This makes it slow.

If this was not enough, find insists on wading through the entire
filesystem (relative to the starting point) even if matches was found, 
just to ensure that no additional matches are found - most often
you don't want this functionality (unless you're making a backup).

>>Find is also complicated to use for non-trivial tasks, and the syntax  is
>>often confusing to non-wizards, so specialized shell-scripts or programs
>>are often more intuitive and faster to create and maintain.

>This is getting into a typical religous issue, so I won't say much in
>response other than the fact that if someone knows enough about the system
>to creat shell scripts and/or programs it behooves them to take an 
>extra few minutes to learn find.

How about grouping selection criterias and the precedence of the -a and
-o (and & or) operators when grouping selection criterias ???

>Find in itself is not complicated (just some name selection logic) and 
>should be one of the tools that anyone writing shells is intimately aware
>of.  (BTW - I am one of the people that believe you shouldn't be allowed
>to write any shell scripts until you have made a complete pass through
>sections 1 & 1m (or 8, depending upon your OS) AND you should repeat this
>on a regular basis).

I'm not an apprentice in UNIX, in fact I have used the system extensively
for the last 8+ years, and uses find on a regular basis, also with fairly
complicated expressions. Still, there are times when find is not part of
the solution, and shell scripts are more intuitive.

>As an aside, most of the specialized shell scripts that you mentioned will
>usually run a find as part of the script anyway.

Sometimes, but most often good ole ls(1) will do the job nicely and faster.

>But to make the correct selection you should be aware of most, if not
>all, of the tools available (nothing is better than an educated decision).

There might be occasions when faced with the problem:

	The right way to solve problem X is to use tool Z, but in order
	to use tool Z which is either complicated to use or unfamiliar,
	the amount of time used in studying tool Z takes longer than to
	use another tool, that might not be the best, but is faster to
	employ and does the job.

The morale is optimal solutions are good -- but don't forget common
sense, or you'll end up searching indefinetely for the optimal solution
and gets nothing done, when time is critical!!!

					Kim Chr. Madsen

In article <1990Oct7.001518.14216@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
: The morale is optimal solutions are good -- but don't forget common
: sense, or you'll end up searching indefinetely for the optimal solution
: and gets nothing done, when time is critical!!!

Though sometimes you have to take a hit on the current problem so that you
can be better prepared for the next problem.

But yes, balance is needed.  And it's okay for different people to strike
that balance at different points.  The world needs both doers and dreamers.
(And a few people who pretend to do both.)

Larry

In article <1990Oct7.001518.14216@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
>cpcahil@virtech.uucp (Conor P. Cahill) writes:
>
>>This is getting into a typical religous issue, so I won't say much in
>>response other than the fact that if someone knows enough about the system
>>to creat shell scripts and/or programs it behooves them to take an 
>>extra few minutes to learn find.
>
>How about grouping selection criterias and the precedence of the -a and
>-o (and & or) operators when grouping selection criterias ???

For the life of me I couldn't tell you the precedence of any of the 
operators, but I still use them all the time.  If there is any question 
about the precedence (and I have questions about it anytime i use -o) I
just add "(" and ")" to get what I want.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

I wrote...
> >Why use `xargs' when you don't need to ?

Finally, someone replies...

In article <1990Oct5.163050.8835@ibmpcug.co.uk>, dylan@ibmpcug.co.uk (Matthew Farwell) writes:

> 2 points.
> 1) The original posting wasn't about find, it was about another pipe which
> produced filenames on stdout, so comments on xargs were required.
> 
> 2) find / -exec rm -f {} \; spawns rm everytime it encounters a file
> so its very slow and expensive, whereas xargs collects all the filenames
> together, bundles them up into lines which won't exceed the system limit
> and then spawns one job for all of those. Its much more environmentally
> friendly.

1) That is correct.  To many articles are posted as advice that seem to require
   blind faith to use them.  For those of you who haven't caught on, the 
   question was rhetorical, looking for someone to respond.  I say the answer
   to it should have been in the posting that contained it.

   It's only a small gripe, but I'd just like to see people who answer (any)
   questions on the net answer thoroughly, ie with alternatives and pro's/con's
   of each.  People who can't answer like this probably shouldn't be answering.
   After all, a genius is not someone who can simply solve a problem, but
   someone who can solve in numerable ways.

   I'd like to see users of the net using methods we give them with reason, not
   blind faith.

2) This is also true, yet wasn't hinted at in the first article containing it,
   where it perhaps should have been.

   What is more environmentally friendly is bandwidth not being wasted by
   people reverberating questions like `why use xargs ?' all over the net,
   because someone posted answers requiring questions :-)

   Oh well, enough said, back to work...

-- 
George P. J. Turczynski,   Computer Systems Engineer. Highland Logic Pty Ltd.
ACSnet: george@highland.oz |^^^^^^^^^^^^^^^^^^^^^^^^| Suite 1, 348-354 Argyle St
Phone:  +61 48 683490      |  Witty remarks are as  | Moss Vale, NSW. 2577
Fax:    +61 48 683474      |  hard to come by as is | Australia.
---------------------------   space to put them !    ---------------------------

So you like to use this:

    find . -type f -print | xargs rm -f

Interesting things happen here under some versions of xargs if you
have files with odd names that look like command lines, such as:

    echo hi >"foo ; rm -rf /"

Since some versions of xargs (or programs of similar function, such as
"apply") use a shell to execute the indicated command, the shell parses
the file name, splits on the ";", and executes the following part of the
file name as another command, with potentially exciting results:

    rm -f foo ; rm -rf /

Even versions that don't use a shell to run the command often split on
blanks, causing file names to match things you don't intend:

    touch foo bar
    echo hi >"foo bar"
    echo "foo bar" | xargs rm

The above example removes files "foo" and "bar" on Ultrix 3.1C.  File
"foo bar" (which might have been the result of a "find") is not touched.

So be VERY CAREFUL using xargs and friends!
-- 
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
 [129.97.128.64]  Computer Graphics Lab/University of Waterloo/Ontario/Canada