What-ho Ken!
rmm: more than 998 messages for rmmproc exec
So ... looks like this has been that way forever. Right now all calls
to execve() and friends are limited to MAXARGS arguments (which is
currently defined as 1000). Ok, 1 for argv[0], one for the trailing
NULL, that's how we end up at 998.
As I read it ... the actual limit for execve() isn't the number of
arguments, it's the total number of bytes in the argv[] (and
environ[]) array. But I think capping the limit at MAXARGS is fine;
hasn't caused us any problems yet (well, other than this one).
Traditionally I think there's two limits; the total number of bytes for
the strings, including their terminating NULs, and the number of
elements in the array that points to them. The latter may have
influcenced MH.
POSIX now seems to have just the strings and their NULs with argv's and
environ's strings in total having to be 2Ki less than ARG_MAX to allow
the exec'd process room to adjust and exec others. Though xargs(1)
seems pessimistic.
$ getconf ARG_MAX
2097152
$ yes | xargs -e sh -c 'expr $# \* 2; kill $$'
131042
xargs: sh: terminated by signal 15
$
rmmproc: rmmproc
I take it "rmmproc" is your own script?
Indeedy. ~/bin/rmmproc.
I guess the simplest thing to do would be to keep calling rmmproc over
and over until you process all of the arguments. That sound alright
to you?
It would do, and I agree it's simple. In my case though I rename 42 to
,42,1353773276.939344523 where the timestamp is snapped once at the
start of the script. This means all those rmm'd in one go have the same
timestamp, which I find handy. Batching would break that. I'd live
with it if necessary.
Feeding rmmproc filenames on stdin is the normal workaround, LF or NUL
terminated.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers