> 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".
Interesting; I couldn't live without the unseen sequence. My inbox
contains a large backlog of "old" messages which have been read but not
deleted.
> 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. :-)
I'm not familiar with the kind of output fetchmail gives, but you can
certainly use procmail to pipe messages to rcvtty in addition to
storing them. I find rcvtty's notification very useful.
Cheers,
- Joel
_______________________________________________
Nmh-workers mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/nmh-workers
