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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
