[Top][All Lists]

[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: Paul Fox
Subject: Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.
Date: Mon, 26 Nov 2012 17:46:42 -0500

paul vixie wrote:
 > On 11/26/2012 9:42 PM, address@hidden wrote:
 > > Anybody who subscribes to the Linux-kernel list is going to be
 > > deleting about 700 messages a day. So if you took a 3-day weekend you
 > > can be looking at 2,000+ messages to delete. exmh has some
 > > special-case code that does it in chunks of 998 messages at a time. 
 > using argv[] to carry bulk data is gauche. if mh wants to be hacky it
 > can do stuff like that. if mh wants to be an example of good engineering
 > then it has to do something else. what it does ought ideally be portable

so, i've stumbled over rmmproc's limit in the past (and, like others,
have quietly, manually, done it in chunks instead), but i don't think
i've ever seen a similar limit with "rm".  and now i'm wondering, why
not?  certainly this works just fine:

    $ mkdir /tmp/many
    $ cd /tmp/many
    $ touch $(seq 1 100000)
    $ ls | wc -l
    $ rm *
    $ ls

i didn't strace it, but i assume that touch and rm are both executed
just once by the shell.

 > to msdos, since some of us run mail clients there. this means that

(this might be the first time i've seen "runs on msdos" used as a
metric of "fine engineering".  okay, you said "good", not "fine", but
still...  ;-)

 > piping to a subprocess is fine as long as we're not expecting to execute
 > posix "find" or "xargs". pipes and filters and scripts should be
 > makeable out of mh but should not necessarily be on the inside of mh.
 > i'd say that things like rmmproc are fine for singleton messages but
 > that the caller should never use a longer argv than 10 or 20 elements.
 > that could mean calling it repeatedly, unless something else (new as of
 > this thread) like rmmpipe is available, which would take its list of
 > operands on stdin rather than in argv. folks who want atomicity of rmm
 > across sequences so that they can put the same timestamp on each message
 > as they trash it, would have the burden of reworking their scripts to
 > work as rmmpipe rather than rmmproc.
 > paul
 > -- 
 > "When challenging a Kzin, a simple scream of rage will suffice. You scream 
 > and you leap." 
 > _______________________________________________
 > Nmh-workers mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

 paul fox, address@hidden (arlington, ma, where it's 33.6 degrees)

reply via email to

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