Hi, > The workaround is to split argument list into chunks that operating > system can process. "getconf ARG_MAX" is used to determine size of the > chunk.
Two questions on this: 1) People say that 'getconf ARG_MAX' returns the appromixate number of bytes in a command line. [1] But you use it with 'xargs -n', which gives a limit on the number of arguments. Shouldn't the patch use 'xargs -s' instead? 2) The really available values are slightly smaller. On Linux: $ getconf ARG_MAX 2097152 $ LC_ALL=C xargs --show-limits Your environment variables take up 4744 bytes POSIX upper limit on argument length (this system): 2090360 POSIX smallest allowable upper limit on argument length (all systems): 4096 Maximum length of command we could actually use: 2085616 Size of command buffer we are actually using: 131072 On FreeBSD/x86_64: $ getconf ARG_MAX 262144 $ LC_ALL=C xargs --show-limits Your environment variables take up 353 bytes POSIX upper limit on argument length (this system): 259743 POSIX smallest allowable upper limit on argument length (all systems): 4096 Maximum length of command we could actually use: 259390 Size of command buffer we are actually using: 131072 On macOS: $ getconf ARG_MAX 262144 $ LC_ALL=C xargs --show-limits Your environment variables take up 1262 bytes POSIX upper limit on argument length (this system): 258834 POSIX smallest allowable upper limit on argument length (all systems): 4096 Maximum length of command we could actually use: 257572 Size of command buffer we are actually using: 131072 How about being conservative and dividing the limit by 2, to avoid this margin error? Could it be that your patch works only because xargs uses a command buffer of length 131072, regardless of the value you pass to '-n'? Bruno [1] https://www.cyberciti.biz/faq/linux-unix-arg_max-maximum-length-of-arguments/
