sahayman@iuvax.cs.indiana.edu (Steve Hayman) (10/09/90)
>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. Steve -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984 NeXT Mail: sahayman@spurge.bloomington.in.us
lml@cbnews.att.com (L. Mark Larsen) (10/10/90)
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.comlwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/10/90)
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.
What makes you think xargs is the only program that would like to use -print0
output? Think toolbox, man! (That's how Randal would say it.)
find ... -print0 | perl -e '$/ = "\0"; while (<>) {chop; unlink;}'
That doesn't suffer any of the security holes of xargs.
Larry Wall
lwall@jpl-devvax.jpl.nasa.govbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/10/90)
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. On the general grounds of ``modularity'' I'll claim that the separate commands are more useful. I imagine commands other than xargs being able to take that 0-terminated list and do something with it. Modularity aside, it's much, much simpler to add -0 to xargs (a few lines added) and -print0 to find (just change a \n to \0) than to add all of the argument handling of xargs into find. ---Dan
lvc@cbnews.att.com (Lawrence V. Cipriani) (10/10/90)
In article <9365:Oct910:43:4590@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) 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. It does, sort of: find . -print | xargs -i your_command '{}' but, since the -i option executes your_command once per file it will be very slow. -- Larry Cipriani, att!cbvox!lvc or lvc@cbvox.att.com