Jim Dennis wrote about his attempt to reprocess stored mail with
formail -s /path/to/procmail < procmail.backup:
| Well, I said I'd mess it up. I really should have
| copied procmail.backup to some other file and
| used THE OTHER FILE in this formail command.
|
| Naturally the first recipe in infobot's procmailrc is:
|
| :0c
| procmail.backup
|
| Rather than leave that to the imagination I'll just
| mention that the file got to be about 500K before
| I noticed it.
Yes, I've not only made that mistake myself but once I made it by botching
the effort to avoid it!
[BTW, it appears that procmail.backup is a file, not a directory. If you're
on a UUCP connection and get your incoming mail in sudden rushes, you need
a local lockfile there even more so than you would on a live Internet link.]
Copying (or moving) the input to another filename is a good fix; just be
careful not to pick a filename that also appears in procmail's rcfile as
a place to save mail, or you'll run into the same problem.
formail's own available protection against it is the -[number] option.
Unless I have a tried-and-true tested script or alias that I know will not
append to the input, I check the number of messages I'm going to feed to
formail -s and if, for example, there are seventeen,
formail -17s program args
or if I want to skip the first two of the seventeen,
formail +2 -15 -s program args
[though if I knew the program wouldn't append to the input, I would leave off
the "-15"].
Unfortunately, formail cannot act that way by default, because it would take
two passes: one to see where the input ends and one to split it and feed it
to the named program. That would be a real bear if formail is getting input
from a pipe, because it would need to store it all for the second pass. You
would need one program (another formail call, or grep, for example) to get
the number of messages and then you could run formail -- and if the input is
from a pipe, you'd need to store it in a file first, I suppose.
There are other workarounds, such as using formail -ns instead of formail -s
[there are significant trade-offs there] or testing whether procmail is run-
ning interactively before you save to a file that you might be refeeding.
However, checking the number of messages in the input and telling formail to
stop after that is the surest way.