Hi Xavier,
procmail can also store into MH folders, e.g. ~/mail/inbox, IIRC,
removing the need for the inc stage.
Hum, but then, how "MH" knows about new messages ? I think I am
missing something. Does inc just store messages and nothing else or
does it do some other stuff (such as updating a "database of new
mails") ?
inc(1) reads from the mail spool file, e.g. /var/spool/ralph, and
creates individual ~/mail/inbox/[0-9]* files before emptying the spool
file. It mucks around with the `unseen' sequence too, although that's
not something I've found useful; that's the `database of new mails'
you're referring to in a way. MH `knows' about the new ones just
because scan(1) finds the files exist when you do "scan last:20".
Since fetchmail can do more complex fetching than inc, likewise
procmail can do more complex filtering than slocal I suggest you
leave them to do the work they're already doing and either have
procmail put stuff in your inbox or create ~/bin/inc that kicks off
fetchmail and then runs /usr/bin/mh/inc.
Problem is I am not sure how procmail and mh can cooperate. Do you
have any procmail examples ?
See procmailrc(5) for the description of the mail folder ending in "/."
-- search for `mh', and see procmailex(5) for many examples including
ones using MH folders, again search for `mh'.
If you want bash(1) or something else to tell you there's new emails
deposited in +inbox by procmail then I guess you can muck around with
the MAIL environment variable that bash watches and write stuff to $MAIL
in procmailrc; perhaps someone who uses procmailrc to update +inbox
will say what they do. Me, I fetchmail, observe its output, and maybe
inc. :-)
Cheers,
Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers