On Fri, 20 Dec 1996, Tony Nugent wrote:
Then I can assume that procmail treats INCLUDERC files like
subroutines, with control going back to the caller. This is good, as
I now understand that it is possible to totally modularise
~/.procmailrc.
The only caution is that setting or clearing HOST to anything but
the current hostname will cause procmail to stop processing and
proceed to the next file argument on the command line, if any.
Thus, if you clear HOST in a sub-recipe file, procmail will NOT
return from it, but will proceed to the next recipe file on the command
line. If there is no other arguments on the procmail command line,
then procmail stops.
They are _linked_? Ahh, now I understand what the man page is talking
about. But what if I want them to be separate messages (ie, not
hardlnked with the same inode)? (Indeed, is there any advantage -
apart from the saving in disk usage, for using hardlinks over straight
copies).
Well, if you use "forw -inplace" or "repl -inplace", as I do, then
when MH annotates the messages which you are forwarding, or to which
you are replying, then *all* of the linked messages will see the
annotation.
Also, the disk space saving, over time, can be considerable, if you
are a compulsive archiver.
One question about using procmail with mh... when procmail deposits
messages into mh folders in numbered sequences, the `unseen' sequence
isn't updated.
Yes. I've mentioned this before in this list (check the procmail
archives for mail from me), and, even included an example
wrapper shell script which does the locking around the MH calls.
Essentially, you must make MH observe the same locking protocol as
procmail uses.
G'luck and Happy Holidays!
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com> http://reality.sgi.com/aks