nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeffrey Honig
Subject: Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.
Date: Sat, 24 Nov 2012 22:25:04 -0500

Ralph Corderoy <address@hidden> wrote:

> 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.

My rmmproc moves all files into +trash and annotates them with a
``Trashed'' header (which includes a date).  I clean out my trash folder
after a few days, based on that annotation. 

> Feeding rmmproc filenames on stdin is the normal workaround, LF or NUL
> terminated.

Changing the way rmmproc is called would break all out existing scripts.

Thanks!

Jeff

-- 
Jeffrey C. Honig <address@hidden>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]