dattier(_at_)wwa(_dot_)com (David W. Tamkin) writes:
elijah(_at_)netusa(_dot_)net asked,
| Does procmail support stuff like:
|
| FLAGS=W
| USELOCK=stage-one-lock
|
| :0 $FLAGS : $USELOCK
| * some-condition
| | eval $SOME_ACTION
With regards to the $FLAGS and $USELOCK, yes that will work. In fact,
after it sees the leading ':', procmail does variable expansion on the
rest of the line before looking for the condition count (usually zero
for auto detection), the flags, and the possible second colon and
locallockfile. The following really does work:
FOO = '0 b'
: $FOO `echo :somefile.lock`
(Kids: don't try this at home!)
procmail will see ":0 b : somefile.lock" and run with it. Once again,
we've found a way to totally obfuscate one's .procmailrc.
No, because it will not find an executable named "eval" in any directory
in $PATH. This may work:
:0 $FLAGS : $USELOCK
* some-condition
| $SOME_ACTION
...though redirections and other shell syntax in SOME_ACTION won't be
recognized.
And this should always work, depending on the effect of eval on the contents
of $SOME_ACTION, because the semicolon will force a shell, which will under-
stand "eval" (if your $SHELL is set to something that doesn't understand
"eval", then I would assume you wouldn't try this anyway):
:0 $FLAGS : $USELOCK
* some-condition
| eval $SOME_ACTION ; # or eval "$SOME_ACTION" ;
# or even eval \'"$SOME_ACTION"\' ;
The maximally correct choice appears to be:
:0 $FLAGS : $USELOCK
* some-condition
| eval "$SOME_ACTION" ;
This preserves extra-whitespace in SOME_ACTION which eval might not
end up splitting. For example:
SOME_ACTION = "echo 'bar baz' >/tmp/foo"
would put "bar baz" (only a single space) in /tmp/foo if $SOME_ACTION
isn't double quoted for the eval.
Yes, shell quoting should be taken out and shot, except that it's mostly
too late.
Philip Guenther