At 00:03 2008-09-17 -0500, David W. Tamkin wrote:
You're arguing the case for having a $NL variable to represent one
newline, and you seem to think I'm arguing against it.
Not entirely - I saw that you'd conceded that it's half one half the other
- I'm saying that defining and then using $NL is actually less error prone
than not.
I'm arguing against assuming that all other procmail users have assigned
the NL variable, let alone that they've all assigned it to equal one newline.
One of your earlier statements is that if you give people code with a
newline between quotes, they'll copy it wrong.
Not that they'd copy it wrong - more that having a dangling close quote on
a following line invites a user to enter recipe text within the quote, or
to accidentally edit out the trailing quote - which will chuff up the
recipe for sure and leave them wondering (remember, some people can't
manage to post a logfile excerpt <g>). If they want newlines at the end of
different log statements, there would be dangling close quotes in many
places throughout an rcfile (or collection of same).
My reply was that if you give them code with $NL in it, you'll need to
assign a value to NL earlier in the code that you give them, so you'll
still be sending out code with a newline between quotes that they'll copy
wrong.
Ah, but the top of THAT rcfile could always define it if necessary (say in
a doc-block -- these variables should be defined -- if you define them in
your main .procmailrc, you can remove these lines from here), and, since
$NL is being used in LOG emissions (though I'm certain it might find use
elsewhere), if it is in fact undefined, or set to something else, at least
the LOG will show it, without hosing the rcfile parse. I refer again to
the ONE location where you'd put a big caution about the intentional line
bridging...
It is pretty much a moot point though - the people most likely to screw up
an rcfile don't actually _read_ any of the exchanges on this list - they
post their obscure chunk of rcfile, or just say "something I'm doing
doesn't work, how do I do it?" <g>
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail