procmail
[Top] [All Lists]

Re: duh - formail and variables for switches?

2002-04-05 15:08:01
PSE-L(_at_)mail(_dot_)professional(_dot_)org (Professional Software 
Engineering) writes:
At 14:39 2002-04-05 -0600, David W. Tamkin did say:
 :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).

The key problem is that with shell quoting and variable expansion, word
splitting (the process of breaking text into separate arguments) is all
or nothing for variable values.  Unless you use 'eval' to reparse the
line, there's no way to say "break on _this_ space but not _that_ one".

Fortunately, that's not really necessary here: the first value for any
formail option doesn't have to be in a separate argument.  So, you
can say:

        BOUNCEOWNER = "-IBcc: $BOUNCER"

then later:

        | formail ... ${BOUNCEOWNER:+"$BOUNCEOWNER"}

That won't work for -R, because the new field name has to be in a
separate argument.  For that you could use a separate variable, ala:

        | formail ... ${RENAME:+"$RENAME" "$RENAMENEW"}


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).

Well, if you're really careful, you could use 'eval' and reparse it all.
You need to think hard about what gets expanded when when you do that.
Anything that is extract from message, for example, should be left
unexpanded until the eval, so that it isn't reparsed, so:

        FORMAILOPTIONS = "$FORMAILOPTIONS -I\"Subject: Re: \$SUBJ\""
...
        | eval formail "$FORMAILOPTIONS" ;


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).

Quotes inside a variable value are not special to the shell.


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:

When procmail sees the colon that starts a recipe, it performs variable
expansion on the rest of that last.  Just put the 'c' flag (or not)
in a variable.


Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>