So, is there a reason not to make the arg. list length grow dynamicly?
So, is there a reason not to make the arg. list length grow dynamicly?
Posted Aug 27, 2007 10:48 UTC (Mon) by liljencrantz (guest, #28458)In reply to: So, is there a reason not to make the arg. list length grow dynamicly? by sayler
Parent article: The vi editor causes brain damage
Awesome!
The xargs command is a horrible, evil kludge invented in an era where memory and processing power were many orders of magnitude more expensive. It has _no_ place in a modern operating system. Linux should have worked this way from the start.
I really hope that this patch will make it into the distros ASAP, it will make my life loads easier since I regularly run into this bug.
Posted Aug 30, 2007 15:24 UTC (Thu)
by welinder (guest, #4699)
[Link] (4 responses)
find . -type f -print | xargs -n100 grep oink /dev/null
(Bonus points for knowing why that /dev/null is there and points
Posted Aug 30, 2007 16:53 UTC (Thu)
by stuart_hc (guest, #9737)
[Link] (1 responses)
Posted Aug 30, 2007 21:28 UTC (Thu)
by dfsmith (guest, #20302)
[Link]
Posted Aug 30, 2007 17:54 UTC (Thu)
by zlynx (guest, #2285)
[Link]
IO is usually the limit, but some operations take more time, like a complicated perl -i transform over a whole Linux kernel tree, for example. Or xsltproc.
You can also get to a CPU limit instead of a disk limit these days by using compressed data, either gzipped on disk, or something like Reiser4 with file compression.
Speaking of which, I find most high end workstations quite disappointing these days. Designers need to spend more time adding fast disk.
Posted Aug 31, 2007 14:35 UTC (Fri)
by emj (guest, #14307)
[Link]
Note the -r
I wish there was a better way to do -print0, I mean you can't do a ls -0|xargs -0 ls to skip problems with spaces right?
xargs has very nice applications not related to very long commandSo, is there a reason not to make the arg. list length grow dynamicly?
lines. For example, it enables the "find" and "do" stages to work
in parallel:
for fixing the space problems using the 0 flags.)
The /dev/null argument is there so standard grep will see at least two file arguments and therefore always output the filename of matches. GNU grep adds the extension -H or --with-filename making this trick unnecessary.
So, is there a reason not to make the arg. list length grow dynamicly?
I suspect it's more to do with not hanging on stdin when find doesn't find anything.So, is there a reason not to make the arg. list length grow dynamicly?
Speaking of parallel operations, use find with -n and -P for more fun. Really great on SMP systems.So, is there a reason not to make the arg. list length grow dynamicly?
find . -type f -print0 |xargs -r -0 -n100 grep oink
print0 is an evil kludge