On Fri, Oct 24, 2008, Bart Schaefer wrote:
>On Fri, Oct 24, 2008 at 8:48 AM, fred smith
><fredex@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> I've always understood it to be an issue with commandline length: somewhere
>> (probably in bash) there's a limit on how big a buffer is/can be used for
>> storing the comamndline.
>
>There are two possible buffer limits one could encounter: tty driver
>input line buffer (which is not an issue for bash because readline
>avoids it) and kernel exec space for the arguments plus environment
>passed to a new process. Only the second one causes the error message
>that started this thread, and previous posts have pointed out that
>recent Linux kernels have effectively removed that limit (see message
>from Jeremy Sanders).
While current Linux kernels may have removed the limit, this has
been a common issue on all *nix systems for decades, which is why
xargs was written.
As a general rule, it's best to use find to pipe lists to xargs
rather than depend on the characteristics of the underlying
system. This might be called defensive programming, as it
insures that scripts will work anywhere, not just on the system
you are using today.
Programming to the lowest common denominator may not feel sexy,
but it can prevent many headaches in the future. I spent quite a
bit of time many years ago getting a large FORTRAN system working
that had been written on a system that use 7 character variable
names where standard FORTRAN only permitted 6 (it was amazing how
many of the variable names differed only in the 7th character).
While this would be relatively easy to deal with today, it was a
bitch when all programs were on 80-column punch cards.
Bill
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186
We shouldn't elect a President; we should elect a magician.
Will Rogers
