Collin advised Joel,
| # Don't forget to set shell...
| SHELL=/bin/sh
Probably not necessary here, but it's a good idea in general.
| :0hi
| SUBJECT=| formail -xSubject:
That wastes a process (and it also leaves leading space intact in the
subject). Better,
:0 # brackets enclose caret, space, tab
* ^Subject:.*\/[^ ].*
{ SUBJECT=$MATCH }
| :0hi
| TO=| formail -xTo:
Same comments. Better,
:0
* ^To:.*\/[^ ].*
{ TO=$MATCH }
| # save shellmetas
| Oldmetas=$SHELLMETAS
|
| SHELLMETAS==
| :0
| | SUBJECT="$SUBJECT" TO="$TO" /home/user/script
|
| # restore shellmetas
| SHELLMETAS=$Oldmetas
| The SHELLMETAS business is to force a shell to be executed, which will
| export $SUBJECT and $TO when executing /home/user/script .
Er, no, and no again.
First, procmail exports all variables set in .procmailrc that have normal
variable names, so there is no need to specify them on the command line for
the script to know them. Therefore there is no need to force a shell.
Second, if you did want to force a shell for a command with no characters
from $SHELLMETAS, you wouldn't need to scrap them all and replace them with
a character from the command; you'd just add a trailing semicolon:
:0 flags
* conditions
| a command with no metas that needs a shell to run it right ;
Third, if we really had to do it the way you showed, Collin, I wouldn't
write
SHELLMETAS==
because it's too easy for the user to misread it and leave out one equal
sign. I'd make it
SHELLMETAS = ' '
or if we're positive that the command will be invoked by at least a partial
path and not solely the basename,
SHELLMETAS=/
but #2 precludes #3, and here #1 precludes #2, so all Joel needs is
:0
| /home/user/script
and the script will receive the exported values of SUBJECT and TO.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail