Edward Peschko wrote: > I've been going through my work habits, trying to pick out > annoyances, inefficiencies etc, and one of the big ones > I've come across is running into 'arg list too long' errors.
Of course there is an FAQ on this: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Argument-list-too-long Specifically this recent change to the linux kernel would be interesting to you. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba 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. So if you are patient enough you won't have to worry about it in the future. > One of the big culprits for this is grep. I try to pass a too long > list, and get that error.. I imagine this will be due to expanson of file arguments? In which case you should, or at least could, use find. find . -type f -exec grep PATTERN {} + But grep does have built in recursion support. Even though I personally believe it shouldn't because it violates the unix philosophy and isn't needed since it is already in find. grep -r PATTERN . > I know that xargs, etc. can get around this error but it > is a pain to remember the syntax for this, and I > don't think it can quite duplicate an integrated argument. Using xargs with zero terminated strings works perfectly well. But it isn't standard and so can't be used portably. > So I was wondering if a patch, giving a file containing a > filelist would be accepted for the next version of grep? Obviously by my response I don't think something like that is needed. Is there a reason that you can't use one of the several existing methods? Can you provide some examples where not having this feature is significantly problematic? Bob
