At 14:39 2002-04-05 -0600, David W. Tamkin did say:
Since there are no characters from $SHELLMETAS in the command string, I don't
have to ask what your shell is.
For procmail, it's /bin/sh (which on this machine is a bash alias). I'd
first expected that it might be a shellmetas-ism, but since there were no
shell characters, I couldn't make heads or tails of it. I still can't.
:0
| formail -I "Subject: [BOUNCE ADVISORY] blah blah" \
-I "From: $BOUNCER" \
-I "To: somebody(_at_)there(_dot_)com" ${BOUNCEOWNER:+-I "Bcc: $BOUNCER"} \
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, and where formail just gets told the
options (rather than invoking formail multiple times, since in fact,
formail is being invoked on an excerpt from the body to generate a new
header which is being piped to sendmail, and I want that to happen only ONCE).
That's not to say that I cannot use this - it just means I have to
expressly put in each option, instead of having them externally
managed. The scheme I was trying to do would have actually amounted to
option assignments looking like:
FORMAILOPTION="$FORMAILOPTION newformailoption newformailargs"
In such a way that each option would simply be concatenating itself upon
the previous string (if any).
Any idea what is actually happening to $BOUNCEOWNER when passed as a direct
argument to formail? If I pass it to echo instead, everythinng except the
first argument is de-quoted (an effect of echo), though if I move it to the
head of the argument list, it looks just fine (with quotes, etc).
Another is to forget about -t:
That would work assuming that addressees are the only thing I'm looking to
modify in this fashion. They aren't. Yes, it's shown that way in the
example - perhaps I should have used a different specific example - the
X-Loop or Subject for instance.
Thanks for the alternative suggestions though.
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). This is being used in a situation where
you might be sending an advisory message AND passing the message along
anyway, or you might be sending an advisory indicating the message had been
discarded. The copy seems wasteful, but it is easier to maintain than
having two copies of the filter logic itself, and I haven't stared at it
long enough for the nesting trick to come to mind (because the copy can't
actually deliver to default - I need it to continue along and out).
Likewise, I have a need to sometimes run a filter against the headers
(bouncing against the message itself), or against the body (bouncing
against the headers contained within a bounced message). As yet, I haven't
come up with a solution to this - I am still running nearly cloned set of
filters to do this (the only difference is the 'b' flag), and as the
conditions grow, it gets ugly real fast.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail