Rik Kabel <rik(_at_)netcom(_dot_)com> writes:
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.
Open mouth, insert foot. Double quotes *are* special inside of conditions
being reread because of the '$' condition special. Indeed, in a condition
with the '$' special, whitespace is compressed between double quotes,
but not outside of them! For example:
* $ foo bar" "baz
Causes in the line
"foo bar" "baz"
to be fed to procmail's sh syntax parser, and thereby results in the
regexp:
foo bar baz
The behavior matches the literal description on the manpage, but doesn't
seem very intuitive to me. As for whitespace after a newline, see below.
...
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?
Hmm. That paragraph was added to the CAVEATS section of the manpage
on 1993/11/5. On 1994/1/11 procmail was changed to remove whitespace
following a newline inside a condition being reprocessed by the '$'
condition special, as well as to remove the newline itself if it was
preceeded by a backslash. So, I believe that the only time whitespace
following a newline inside a condition is _not_ skipped is when processing
a simple '?' special. Compare:
aragorn% cat rcfile
:0
* ? echo "sd fkjf \
dsfhskj\
sjhskjf" > baz1; true
* $ ? echo "sd fkjf \
dsfhskj\
sjhskjf" > baz2; true
* ? echo 'sd fkjf \
dsfhskj\
sjhskjf' > baz3; true
* $ ? echo 'sd fkjf \
dsfhskj\
sjhskjf' > baz4; true
{ }
HOST
aragorn% procmail ./rcfile </dev/null
aragorn% cat baz1
sd fkjf
dsfhskj
sjhskjf
aragorn% cat baz2
sd fkjf dsfhskjsjhskjf
aragorn% cat baz3
sd fkjf
dsfhskj
sjhskjf
aragorn% cat baz4
sd fkjf dsfhskjsjhskjf
aragorn%
So, does everyone follow that?
Philip Guenther