Ken wrote: > It seems reasonable to want to be able to invoke nmh commands from > rmmproc, although that was never clearly defined as reasonable (or > even if it was expected to work).
I think this man page note indicates that it was considered reasonable, though hazardous without some minimal care: rmmproc must NOT call refile or rmm without specifying -normmproc, or you will create an infinite loop. And the -normmproc switch was added specifically to support that. > Possibilites that come to mind are: > > - Update the sequence file _before_ calling rmmproc(). This would > happen in the folder_delmsgs() routine. This technically involves > an API change, but the nmh API has no real definition and only two > callers, so I'm not really worried about that part. I vote for that. > - Do nothing. Not as weird as it sounds; if messages aren't on the > sequence, they'll get removed next time the sequence file is written. Yes but an intervening folder -pack would mess that up. > - Reread the sequence file after deleting the messages but before > writing it out; possibly challenging because the messages will be > gone, but they should be removed anyway. What's the advantage of this over door #1 (update before calling rmmproc)? If it just to minimize API/code changes, I don't think that's enough. > - Set an environment variable to indicate that subprocesses > shouldn't open or modify the sequence file. I'm not fond of environment variables. While they can be useful to modify the behavior of rmmproc, etc., I don't think that's the right thing to do here. David _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers