Hi,
Again, thanks to everyone whose helping me with this. Hopefully,
when we'er done, we'll update the man pages or other doc, as
Mr. Guenther suggests here.
suggested BNF:
condition_line ::= * condition
condition ::= w^x condition
| ! condition
| $ condition
| var ?? condition
| ? command
| regexp
| > number
| < number
But if you think in BNF grammers, wouldn't the above seem obvious?
No. First of all, the BNF you just gave isn't in there. Second, if
it was, it is still missing:
condition ::= command
*Where* did this BNF rule come from???
It is my trial attempt to explain the grammer "correct" syntax
of:
w^x ! command
Stop, think about the grammer
you've now created by adding this rule. You say you've written
parsers. Then you understand what it means for a grammer to be
ambigious. The reason the BNF I gave doesn't include the rule you add
is that it would make it ambigious. procmail would have no way to tell
the differance between a regexp and a command.
OK, I could reverse the challenge, and ask you to find me where
the above syntax (w^x ! command) is found in your BNF or the man
page. This is not an accusation, just pointing out that it's sort
of undocumented.
You're right about my suggesting allowing the ambiguity of regexp
vs. shell command. All that would be needed to cover this "new"
case is:
| ! command
But wait! that's still ambiguous... so how does procmail disambiguate:
:0
* 1^2 ! /usr/kmarsh/bin/counat
from,
:0
* 1^2 ! countat # that's a RE
?
I suppose that negating an RE match is not terribly useful, so
it's not used, but guess what? It's allowed by your BNF.
Okay, so the author of
procmail had to change the grammer to eliminate this ambiguity. He did
so by requiring a command to be preceded by a '?'. Then he documented
this on the manpage.
OK, but left the (w^x ! command) undocumented.
If you want to negate the return code of a command as a condition, you
must say:
* ! ? commmand
But that's not what Lars Kellogg-Stedman suggested (assuming that it
works, which I do):
:0
* 1^2 ! /usr/kmarsh/bin/counat
Did he get it wrong? Like I said, I tried the syntax you give here,
and it worked like procmailrc's man page says it would, and not
like the procmailsc man page said.
The BNF isn't in the manpage because a) 90% of the people reading the
manpage don't understand BNF, and would be confused/scared by it; and
b) those that do understand BNF (or even know what it stands for) are
likely to guess that you can use multiple special flags on a condition
line, try it, and find it works. And there's always the source code
for really strange questions.
Granted, there's the source. I would expect one example, though.
No offense, but what does "one per line" mean to you?
It's not the "one per line" that I was arguing about. I was never
trying to put more than one action line. It's the correct grammer
of the weighted scoring code that was under discussion.
If you're frustrated with the manpages, fix them.
Sure, I'll be happy to. Once I figure out what to put in them.
Come up with a
description/structure that is a) correct; b) clear to a newbie; c)
complete; d) useful for the intermediate user; and e) will server as a
reference for the experienced. Submit it to Stephen and see what he
says. Keep in mind that Stephen believes that (a) and (b) are the most
important.
Lars Kellogg-Stedman's example pretty much fits that criteria... I
wonder, where did he learn it? Did I miss something? Perhaps it's
in the smartlist code or something?
Before you heckle someone's documentation, try writing a replacement.
I have to admit that I was pretty peo'ed. Fortunately, you all on
the list have been very helpful. I'll be glad to update the pages
once I'm done experimenting.
There have been a couple times I've found passages in the manpages
slightly confusing or misleading on technical points, but when I've
tried to rephrase them in a clearer fashion, they've come out more
technically correct, but they've also obscured the main point, such
that the big picture would be lost in the details. In a manpage
destined for beginning users, the Big Picture is much more important
than any detail, and I think Stephen has done a very good job of
presenting the big picture without losing the details for those how
look and *think*.
I've been corrected in the past on my inability to read man pages,
I'll admit. This one syntax, as far as I know, just isn't in there.
Maybe you should just submit some examples for the procmailex(5)
manpage that demonstrates some more condition possibilities...
OK.
Ken.
-------------------------------------------------------------------------
Mail: kmarsh(_at_)charm(_dot_)net | Edit a binary .INI file, then
tell
WWW: http://www.charm.net/~kmarsh | me that UNIX is too complicated.
-------------------------------------------------------------------------