I had written,
| > in fact, I believe it can hurt -- or help -- by causing double
| > interpretation (something like sh's eval).
| Indeed so. It's something I feel could be very useful...but I've not
| yet had a use for it.
| The rcfile fragment:
| * ? echo $MYVAR >output1
| * $ ? echo $MYVAR >output2
| results in:
| $ cat mail/output1
| $ cat mail/output2
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
$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
* $ ? command $BLOW outputfile
procmail would have to expand $BLOW in order to realize that it needed
procmail mailing list