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 23, 2007 14:44 UTC (Thu) by sayler (guest, #3164)Parent article: The vi editor causes brain damage
http://thread.gmane.org/gmane.linux.kernel/571913
> It would be very handy if the argument memory space was expanded.
> Many years ago I hit the limit regularly on Solaris, and going to
> Linux with its comparatively large limit was a joy. Now it happens to
> me quite often on Linux as well.
>
done :)
commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
Author: Ollie Wild <aaw <at> google.com>
Date: Thu Jul 19 01:48:16 2007 -0700
mm: variable length argument support
Remove the arg+env limit of MAX_ARG_PAGES by copying the strings
directly from the old mm into the new mm.
--
Paolo Ornati
Linux 2.6.23-rc3-g2a677896 on x86_64
Posted Aug 26, 2007 8:58 UTC (Sun)
by wolfgang.oertl (subscriber, #7418)
[Link] (2 responses)
Posted Aug 26, 2007 23:22 UTC (Sun)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted Aug 29, 2007 13:30 UTC (Wed)
by nix (subscriber, #2304)
[Link]
(IIRC, it used to start small and work up, but that was much too slow).
Posted Aug 27, 2007 10:48 UTC (Mon)
by liljencrantz (guest, #28458)
[Link] (5 responses)
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?
I hope this won't cause breakage in the detection of max. arg. length of autoconf.So, is there a reason not to make the arg. list length grow dynamicly?
Shouldn't be a problem. Apparently autoconf starts large and works backward. (I'm just relaying a discussion I saw on LKML though; I don't have first-hand knowledge here)So, is there a reason not to make the arg. list length grow dynamicly?
Indeed it does (although actually it's libtool).So, is there a reason not to make the arg. list length grow dynamicly?
Awesome!So, is there a reason not to make the arg. list length grow dynamicly?
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