[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Artificial argv limits.
From: |
David Levine |
Subject: |
Re: [Nmh-workers] Artificial argv limits. |
Date: |
Tue, 27 Nov 2012 08:30:48 -0600 |
Ralph wrote:
> David Levine wrote:
> > Paul F. wrote:
> > > (one way to reduce the likelihood of this, and of the original
> > > overflow issue, might be to pass the message arguments to rmmproc in
> > > the same form that they were received by refile. currently "refile
> > > all" causes a call to rmmproc with a full enumeration of message
> > > numbers. if "refile all" instead caused "rmmproc all", on the
> > > assumption that the same expansion would result, then the original
> > > invocation of refile would be as likely to fail as rmmproc. there
> > > are probably subtleties to this i'm not getting right now.)
> >
> > I think this should work. rmmproc could call "pick <args>" to get the
> > same expansion.
>
> It seems a bad idea to me. It's just punting the expansion problem
> further downstream. A plain `pick <args>' would take my ~/.mh_profile
> into account and my `lp', last picked, sequence would get trampled.
> rmmproc's task is to deal with the files, that should be its interface.
Good point. It would also break existing rmmproc's.
I saw your rmmprocopt later, that seems like the
best solution.
David
- Re: [Nmh-workers] Artificial argv limits., (continued)
Re: [Nmh-workers] Artificial argv limits., David Levine, 2012/11/26
Re: [Nmh-workers] Artificial argv limits., David Levine, 2012/11/26
Re: [Nmh-workers] Artificial argv limits., David Levine, 2012/11/27
Re: [Nmh-workers] Artificial argv limits.,
David Levine <=