Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.

[Ralph Corderoy]

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.