On Fri, 09 Jan 2015 09:04:36 +0000, Duncan wrote: > Jim Henderson posted on Thu, 08 Jan 2015 21:27:05 +0000 as excerpted: > >> On Thu, 08 Jan 2015 19:02:20 +0000, Jim Henderson wrote: >> >>>> That is of course assuming there wasn't some bug in your regex or the >>>> like, that failed the expected match. =:^\ >>> >>> My initial instinct was that it should have matched, but I realize now >>> that the address I put in didn't escape the '.' characters, which may >>> be causing it to fail. I see that the From: rule example does, so >>> I'll try that when I have a minute free today. >> >> Nope, changed the rule and no change. > > Yeah. Failure to escape the '.' characters (which in regex match any > single character unless escaped) would simply result in, for example, > sample.com and samplexcom both matching an unescaped sample.com regex > (you'd use the escaped form, sample\.com, to match the dot > specifically). > > So the unescaped form would result in additional false matches, not > additional match-failures, which if it's match-failures you're seeing, > means the unescaped . can't be the reason. > > (Unless of course there's a bug, but the actual regex processing code is > surely library code, not pan itself, and if there was a bug in that > you'd very likely be seeing it in other packages depending on that lib > as well...)
Yep, that made sense to me just after I did it. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
