Paul Bartlett quoted Era Eriksson,
E> Just fire up procmail from the command line and feed it a test message.
and commented,
B> Suppose while I am testing, legitimate mail comes in asynchronously?
Good point, Paul, but there are any number of ways to take care of that.
1. cp your .procmailrc to another name, make the changes in the copy,
and test it by running
procmail name-of-test-rcfile < file-containing-test-message
or
formail -s procmail name-of-test-rcfile < file-containing-test-messages
or
cat files-containing-test-messages | formail -s procmail name-of-test-rcfile
as appropriate.
If you must test it with your live ~/.procmailrc, there still are ways:
2. BEFORE you name a logfile (this is impossible once you have named a
logfile, even if you have since unset the LOGFILE variable),
:0
* test -t 2
{ INTERACTIVE=yes }
Then INTERACTIVE will equal "yes" for mail fed to procmail from the command
line but will be unset for mail delivered by the MTA or sent to procmail by
a cron job.
Then, later in your rcfile, though you may have set a logfile, you have the
INTERACTIVE variable as a memo from back when you could tell. So wherever in
your rcfile the code to be tested appears, just add the condition
* INTERACTIVE ?? .
to the recipe, or if there are a number of recipes, wrap them in braces:
:0 # perhaps with a `c' to keep a copy for the original code
* INTERACTIVE ?? .
{
code to be tested
}
Remember, this will work only if you use that first recipe before naming a
logfile.
3. If procmail was invoked via a .forward file and not as the MDA, you can
use this method. Here is my .forward:
"| IFS=' ' && $HOME/priority/procmail -f- DOTFWD=yes #dattier"
[Guess I should get bolder and put "exec" in there.] This way the variable
DOTFWD is set to "yes" for any mail delivered via .forward but left unset
for any mail I play around with from the shell prompt.
But again, while this method avoids the extra test in .procmailrc that #2
needs, it works only if mail went through a .forward and not if procmail was
invoked as the MDA.
4. You can always add conditions to the test code so that it operates only
on mail from you and only on mail with certain keywords in certain places.
Anyone out to send you mail forged as if you sent it to yourself is not going
to know the additional conditions.
5. Here's a mixture of #1 and of the reverse of #3: add a condition like
* TESTING ?? ^^youbet^^
to or around your test code, and invoke procmail this way:
procmail TESTING=youbet < file-containing-test-message
or
formail -s procmail TESTING=youbet < file-containing-test-messages
or
cat files-containing-test-messages | formail -s procmail TESTING=youbet
as appropriate.