Philip asked:
Rik Kabel <rik(_at_)netcom(_dot_)com> writes:
...
Care must also be taken in condition lines which have a $ flag, and
are therefore parsed according to sh parsing rules (under which, for
example, multiple consecutive spaces and tabs may be treated as a single
space). There is also a warning about the way leading whitespace on
Not quite. To quote the procmailrc(5) manpage:
$ Evaluate the remainder of this condition according to
sh(1) substitution rules inside double quotes, skip
leading whitespace, then reparse it.
Whitespace is therefore never compressed inside of the resulting
expansion, though leading whitespace is stripped. (Actually, it's
more like substitution rules inside a here-doc, as double quotes aren't
special.)
Sorry, you are quite right. I was thinking about actions (in particular,
actions which cause a shell to be forked) but writing about conditions.
continued regular expression condition lines is handled. It is handled
differently when both inside quotes and subject to a $ flag than at
other times.
I'm not sure I understand what you're saying here: conditions are never
"inside quotes". Can you give an example?
Simply a reference to the caveat in PROCMAILRC(5) which reads:
Leading whitespace on continued regular expression condition
lines is usually ignored (so that they can be indented), but
not on continued condition lines that are evaluated
according to the sh(1) substitution rules inside double
quotes.
Of course, I didn't get it quite right. Conditions aren't inside quotes,
as you say, although I meant not whole conditions, but quoted text
within them. What I should have done (other than simply quoting the
caveat complete) was to say that leading whitespace on continuation
lines in some conditions (those not interpreted according to sh(1)
substitution rules) is ignored, and on others it is not ignored. I am
hard pressed, however, to give an example of such a condition line.
Perhaps you or someone else on the list can point to one?
--
Rik Kabel Old enough to be an adult
rik(_at_)netcom(_dot_)com