Sean followed up,
| While this is workable, it presumes the option passed is a specific header
| - I'm actually trying to make several of the formail actions things which
| are compiled elsewhere in the script ...
Well, you hadn't indicated that before. Still, you can gather up all the
options in variables and use them all on formail's command line as I
illustrated with that one. The suggestion about killing $SENDMAIL's -t
wouldn't apply then, as you noted.
| Something else I wanted to do was deal with optional 'c' flags -- the best
| I could come up with for that (in order to avoid duplicating complex
| recipes), was to just use 'c' anyway, but to have the rule followed by:
|
| # ditch optional copy from previous recipe if it was unwarranted.
| :0A
| * ! FILTER_OPTIONS ?? [ ]COPY\>
| /dev/null
|
| (of course, assume the previous recipe itself didn't use the A flag, but
| that happens to be the case here).
As Philip has said, use a variable for the flag; put this first:
copy_option # make sure it's unset in case you used it earlier
:0
* FILTER_OPTIONS ?? ( )COPY\>
{ copy_option=c }
and then
:0other_flags${copy_option}more_flags
* conditions
whatever
I do that sort of thing left and right, so I can tell you first-hand that
it's rock-solid. If the variable is last on the line or followed immediately
by the colon for a local lockfile or by the dollar sign of another variable,
then, as you'd expect, the braces are unnecessary.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail