Followup on egrep regex problem...
"M.G. Devour" <[email protected]> Sun, 07 Mar 2010 23:50:19 -0500
| Newsgroups | gmane.mail.smartlist.user |
|---|---|
| Message-ID | <[email protected]> |
--Boundary_(ID_2t1eXdJ4yOZvZ1r5usxkAg)
Content-type: multipart/alternative;
boundary="Boundary_(ID_kEIRWOZW2sl9antXxGY6RA)"
--Boundary_(ID_kEIRWOZW2sl9antXxGY6RA)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Jim, Bart, Cary,
Thanks for the responses. I had to be away for a couple of days to take
care of other stuff, which had the benefit of giving me some distance
from the problem, too.
Yes, it appears to be related to the match operator and greedy/stingy
behavior.
Here is a solution I've come up with which *SEEMS* to work:
:0 fhw
* ^content-type:(.*\<)?multipart.*\<(boundary=\/[^"; ]+|
boundary="\/[^"; ]+)
{
TESTVAR = $MATCH
}
Since I have two mutually exclusive cases, quoted and unquoted, only one
of the two branches will match at any time:
boundary=\/[^"; ]+ or boundary="\/[^"; ]+
For a quoted string, the first branch will stop matching on the first
character after the \/, but the second branch should match until the
trailing double-quote is reached.
For an unquoted string, the first branch matches the complete boundary
string, while the second branch will not match to the left of the \/.
It works on well behaved samples with both quoted and unquoted boundary
strings but doens't handle all possible whitespace characters after the
string.
I could try to create a [...] expression with all possible characters
(except ; and " and <space>), but it would break if I miss even one
oddball character that might turn up in a boundary string. The following
looks to be adequate after analyzing a few thousand recent list mails
and testing with several clients and webmail systems...
[-+=/_.:A-Za-z0-9]
Substituting this positive bracket expression in the above recipe
(twice!) seems to work decently well as long as the strings behave
themselves.
Instead of this, it would make the most sense to match anything except
double-quote, semi-colon, or whitespace, except that we don't seem to be
allowed to use control characters, POSIX character classes or shortcuts
( e.g.: [:space:] or \s ) inside bracket expressions in procmail? This
seems to be impossible to do:
[^";<something that stands for all whitespace characters>]
I wish I could understand why?
Cary, you say that procmail doesn't allow escaping of control
characters. Does that mean things like \f \n \r \n \t \v will not be
understood in any context? Or just inside bracket expressions? Can you
or anyone point me to where that's documented, please?
Thanks,
Mike D.
--Boundary_(ID_kEIRWOZW2sl9antXxGY6RA)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: 7BIT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
Jim, Bart, Cary, <BR>
<BR>
Thanks for the responses. I had to be away for a couple of days to take care of other stuff, which had the benefit of giving me some distance from the problem, too.<BR>
<BR>
Yes, it appears to be related to the match operator and greedy/stingy behavior.<BR>
<BR>
Here is a solution I've come up with which *SEEMS* to work:<BR>
<BR>
:0 fhw<BR>
* ^content-type:(.*\<)?multipart.*\<(boundary=\/[^"; ]+|boundary="\/[^"; ]+)<BR>
{<BR>
TESTVAR = $MATCH<BR>
}<BR>
<BR>
Since I have two mutually exclusive cases, quoted and unquoted, only one of the two branches will match at any time:<BR>
<BR>
boundary=\/[^"; ]+ or boundary="\/[^"; ]+<BR>
<BR>
For a quoted string, the first branch will stop matching on the first character after the \/, but the second branch should match until the trailing double-quote is reached.<BR>
<BR>
For an unquoted string, the first branch matches the complete boundary string, while the second branch will not match to the left of the \/.<BR>
<BR>
It works on well behaved samples with both quoted and unquoted boundary strings but doens't handle all possible whitespace characters after the string.<BR>
<BR>
I could try to create a [...] expression with all possible characters (except ; and " and <space>), but it would break if I miss even one oddball character that might turn up in a boundary string. The following looks to be adequate after analyzing a few thousand recent list mails and testing with several clients and webmail systems...<BR>
<BR>
[-+=/_.:A-Za-z0-9]<BR>
<BR>
Substituting this positive bracket expression in the above recipe (twice!) seems to work decently well as long as the strings behave themselves.<BR>
<BR>
Instead of this, it would make the most sense to match anything except double-quote, semi-colon, or whitespace, except that we don't seem to be allowed to use control characters, POSIX character classes or shortcuts ( e.g.: [:space:] or \s ) inside bracket expressions in procmail? This seems to be impossible to do:<BR>
<BR>
[^";<something that stands for all whitespace characters>]<BR>
<BR>
I wish I could understand why?<BR>
<BR>
Cary, you say that procmail doesn't allow escaping of control characters. Does that mean things like \f \n \r \n \t \v will not be understood in any context? Or just inside bracket expressions? Can you or anyone point me to where that's documented, please?<BR>
<BR>
Thanks,<BR>
<BR>
Mike D.<BR>
<BR>
<BR>
</BODY>
</HTML>
--Boundary_(ID_kEIRWOZW2sl9antXxGY6RA)--
--Boundary_(ID_2t1eXdJ4yOZvZ1r5usxkAg)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-disposition: inline
_______________________________________________
Smartlist mailing list
[email protected]
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
--Boundary_(ID_2t1eXdJ4yOZvZ1r5usxkAg)--