David Spector has this recipe,
# SETI League Argus ilst (closed)
:0 w: HamRadio/SETI-argus/$LOCKEXT
*
^(To|From|Cc).*\/(owner-argus(_at_)setileague\(_dot_)org|argus(_at_)setileague\(_dot_)org)
| $RVCSTOR +HamRadio/SETI-argus
and is curious about this error message in his logfile:
/bin/sh: +R: bad option
Rik Kabel suggested,
| s/b RCVSTOR, yes?
Another argument in favor of using basenames instead of pre-set variables to
call executables. Apparently there is no variable $RVCSTOR, so procmail
substitutes null for it and tries to execute +HamRadio/SETI-argus, and ap-
parently there is such a name in a directory in $PATH, but it is not an
executable binary (actually, it's a directory), so the kernel tries to get
/bin/sh to run it by name, and /bin/sh thinks +HamRadio/SETI-argus is an
option string. H, a, and m don't upset sh but R does.
So as Rik said, fix the typo; better, call the program by its name and let
procmail (or the shell if there were characters from $SHELLMETAS in the
command) find it in $PATH. Also,
*
^(To|From|Cc).*\/(owner-argus(_at_)setileague\(_dot_)org|argus(_at_)setileague\(_dot_)org)
would be better as
* ^(To|From|Cc):.*\/(owner-)?argus(_at_)setileague\(_dot_)org
to rule out longer field names that start with those characters and to
make the right side more efficient to parse.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail