procmail
[Top] [All Lists]

Re: [pro] Re: Catch-all list filter

2008-01-04 12:20:07
Charles Gregory wrote:
On Thu, 3 Jan 2008, David Dyer-Bennet wrote:
  
The opening brace is the action.....
      
alternative that I hadn't considered is "a brace isn't a block-grouping 
element" in anything like the sense I'm used to.
    

Actually, the brace works as intended. 

I'm sure it does; just not as I *expected*.

As with other languages, you can
substitute the brace for a single action line. What is 'different' is
that an 'action line' is not a 'stand alone' language element. For
example, you couldn't have THIS for a procmailrc

  :0
  *condition1
  /mailbox1

  /mailbox2

  :0
  *condition3
  /mailbox3

It wouldn't know what to do with '/mailbox2'. 
  

It seems obvious to me, actually; I'd deliver the mesage to both 
/mailbox1 and /mailbox2 if condition1 was satisfied.  Since condition 
lines have the leading "*" to mark them, I see no ambiguity.  Every 
delivery line attaches to the most recent : line (with some rules to get 
it right across {}).

The man page even talks about delivering to multiple mailboxes or 
directories (saying that in the case of multiple directories, hardlinks 
are used); in the absence of saying what the syntax is to invoke that 
function, I was assuming multiple lines.

Okay, that's not how it works, but it's not very clearly explained how 
it *does* work anywhere, and the scheme I describe above is 
self-consistent and parseable.

(Which leads me to the question of what the man page *does* mean when it 
talks about delivering to multiple directories; what syntax does that?)

So that syntax is equally invalid within a brace construct.
Even the syntax:

  :0
  *condition
  {
  action
  } 

....is invalid, for the same reason. As soon as you enter the brace,
you are starting 'fresh' with your syntax.

  
. (dot) is special in procmail regexps and so needs escaping when you
want to match a real dot.  Here I use the character class delimiters to
escape it - it also makes it standout so that _I_ notice that is what I
will get.  As for the [(_at_)], I could probably just have used an @ on its
own, but, again, it does highlight for me, the human with the poor
memory, what the final character of the match is.
      

Plus which, in a few places I have had regex-like code complain about a
bare '@' or treat it specially. So unless you are paying very close
attention, sometimes a generic "[(_at_)]" is just easier to use consistently.
  

Probably in Perl, and maybe TCL, where "@" is an interpolation character 
within double-quoted strings? I know I've run into it in those contexts.

-- 
David Dyer-Bennet, dd-b(_at_)dd-b(_dot_)net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

____________________________________________________________
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

<Prev in Thread] Current Thread [Next in Thread>