Xref: utzoo comp.unix.shell:521 alt.sources.d:947
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!att!cbnews!lml
From: lml@cbnews.att.com (L. Mark Larsen)
Newsgroups: comp.unix.shell,alt.sources.d
Subject: Re: Beware xargs security holes
Summary: "xargs" effectively included in SVR4 find
Message-ID: <1990Oct9.172621.13484@cbnews.att.com>
Date: 9 Oct 90 17:26:21 GMT
References: <1990Oct9.060954.25690@watcgl.waterloo.edu> <63404@iuvax.cs.indiana.edu>
Followup-To: comp.unix.shell
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 26

In article <63404@iuvax.cs.indiana.edu>, sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes:
# >Yeah. xargs should have a -0 option for taking null-separated filenames
# >for its input. find should have a -print0 option for producing similar
# >output.
# 
# So long as you have to modify "find" anyway to solve this problem, why
# not just add "-xargs" option to "find", that would be like the "-exec"
# option only using as many file names as possible at once.
# 
# 	find .... -xargs rm {} \;
# 
# Seems simpler than modifying two programs.
# 

Actually, this is what was done when find was rewritten for SVR4 (among
other things).  The way to use it is to terminate the command with "+"
instead of ";" (e.g., find ... -exec rm {} +)

I never much cared for xargs since it limits you to an argument list of
only 470 bytes.  Since all of the System V UNIX's I know of support argument
lists of at least 5120 bytes (12288 in UTS), this has always seemed like
too small of an upper-limit to me - though it's still better than one exec
per file...

L. Mark Larsen
lml@atlas.att.com