double interpretation

I had written,

| > in fact, I believe it can hurt -- or help -- by causing double
| > interpretation (something like sh's eval).

Martin experimented,

| Indeed so.  It's something I feel could be very useful...but I've not
| yet had a use for it.
|
| The rcfile fragment:
|
|   THIS=that
|   MYVAR='$THIS'
|   :0:
|   * ? echo $MYVAR >output1
|   * $ ? echo $MYVAR >output2
|   rubbish
|
| results in:
|
|   $ cat mail/output1
|   $THIS
|
|   $ cat mail/output2
|   that

Now that's eakyfray, because Martin chose commands that require a shell, and
procmail must have pre-interpreted the second condition before calling a shell
and invoked

 $SHELL $SHELLFLAGS 'echo $THIS >output2'

for it.  The "$" interpretation must have preceded the shell invocation,
unlike what would happen here:

 * ? eval echo $MYVAR >output2

for which procmail would have done,

 $SHELL $SHELLFLAGS 'eval echo $MYVAR >output2'

and "that" would still have shown up in $MAILDIR/output2, of course.

I did not expect $-interpretation to precede the SHELLMETAS scan.  But it
makes sense: what if a variable expands to something that includes a character
from $SHELLMETAS, which wasn't apparent before?  For example, in

BLOW=">"

 :0
 * $ ? command $BLOW outputfile
 whatever

procmail would have to expand $BLOW in order to realize that it needed
$SHELL's help.



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