Era Eriksson wrote,
| Stephen,
|
| Would it be hard to patch the \/ kludge to allow for +two+ \/ tokens
| in a condition line? What I have in mind is something like the \/
| lookahead in lex, or Perl's (?=) lookahead assertion.
|
| So then,
|
| [ ]*\/[^ ].*[^ ]\/[ ]*
|
| would grab the longest non-blank string (with or without embedded
| blanks) and place that in MATCH, but leave off the leading and
| trailing whitespace.
What I'm about to say will not solve the general case, but Era's and Dom's
examples can be handled by the current software. First, Era's:
* lead text[ ]*\/[^ ].*[^ ]
because MATCH will suck up every character that is not a newline (".*")
through the last character that is not a newline, a space, nor a tab.
Now, Dom's:
* ^Return-Path: *<.*-request@
* ^Return-Path: *<\/[^->]+
If some of Dom's subscriptions are to lists where there are two hyphens in
the local part of the return path (say, something like list-name-request),
more recent versions of procmail allow this (the second condition is written
that way in case there is a hyphen in the site or the domain):
* ^Return-Path: *<.+-request@
* ^Return-Path: *<\/[^(_at_)]+-
* MATCH ?? ^^\/.*[^-]
where the second condition extracts up through the last hyphen in the local
part, and the third one examines the new value of $MATCH and extracts through
the last character of it that isn't a hyphen.