On Fri, Oct 24, 2008, Bart Schaefer wrote:
On Fri, Oct 24, 2008 at 8:48 AM, fred smith fredex@fcshome.stoneham.ma.us 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