Philip Guenther suggested to
process(_at_)qz(_dot_)little-neck(_dot_)ny(_dot_)us:
| When you use the '-m' flag to procmail, it assumes that all messages
| will be explicitly handled: it's a filter, not a delivery agent. To
| this end it unsets the DEFAULT and ORGMAIL variables. This causes it
| to bounce messages that aren't 'delivered' before the end of the rc
| file.
|
| The solution depends on what you what it to do. If you just want to
| run procmail with a different rc file, then just put the filename on
| the command line and run, ala:
|
| formail -s procmail new-rc
I'd like to point out that without the -m option, procmail assumes that
any relative paths to rcfiles named on the command line are from $HOME,
unless the path begins with "./". (With -m, all relative paths to rcfiles
are assumed to begin from the current directory, and MAILDIR defaults to
the current directory rather than defaulting to $HOME.) So dropping the
-m may require specifying the path to new-rc if you aren't working in your
$HOME.
| Otherwise you can explicitly set DEFAULT at the top of the rc file.
Yes, or perhaps you could set ORGMAIL, or both.
| However, I wonder if the following recipes better show you goal:
|
| # Find the score by feeding the body into "jmdigest", capturing
| # stdout in the SCORE variable.
| # (if the entire message should be fed, remove the 'b' flag.)
| :0bc
| SCORE=|$MAILDIR/jmdigest -
|
| # save the message into the appropriate file
| :0:
| score=$SCORE
One small comment about the `c' flag on a variable capture recipe. Varia-
ble capture recipes perforce work with a copy of the message, so the `c'
flag isn't needed. In more recent versions of procmail (I don't know ex-
actly when it changed), if you also have a logfile defined and
LOGABSTRACT=all in effect, a `c' on a variable capture recipe will get a
logabstract of the action; in older versions, back to the introduction of
variable capture recipes, it will generate a warning message that the ex-
traneous `c' flag was ignored.