/(?=.*X)(?=.*Y)(?=.*Z)/
[download]

Just another Randal... I like this solution better. :-)

That would match on "XYZZ", of which I got the impression the OP doesn't want a match.

Abigail

Then how about (building on merlyn's solution...)

/^(?=.*X)(?=.*Y)(?=.*Z)...$/

Update: Look at Re: Operator for "these expressions, in any order" (both) (tye++) for a possible stronger solution (X, Y, and Z can be replaced with other regexes, I think)

--MidLifeXis

You can combine a couple of near-solutions:

/^(?=.*X)(?=.*Y)(?=.*Z)(X|Y|Z){3}$/
[download]

If X, Y, and Z are distinct enough, then this should be a total solution. If, for example, X is a subpattern of Y, then it would match YYZ.

Excellent! In my case, X, Y Z... are definitely unmistakable.

I'll just need to check this for performance (yes, just to make my problem more difficult, performance is also very relevant). Fortunately I have something more restrictive to use in lieu of the ".*"...

use Algorithm::Permute;

my @patterns = ();

my $p = new Algorithm::Permute(['X', 'Y', 'Z']);
while (@res = $p->next) {
    push @patterns, join('', @res);
}

my $pattern = join '|', @patterns;

print "$pattern\n";

# give the pattern a test...
while (<DATA>) {
    chomp;
    print "$_ is ", /^(?:$pattern)$/ ? 'good' : 'bad', "\n";
}

__DATA__
XYX
XYZ
ZYY
ZXY
ZYX
XXYZ
[download]

ZYX|YZX|YXZ|ZXY|XZY|XYZ

XYX is bad
XYZ is good
ZYY is bad
ZXY is good
ZYX is good
XXYZ is bad
[download]

Unfortunally, the size of the resulting regex grows exponentially. There are 6 permutations for 3 choices, 24 for 4, 120 for 5, 720 for 6, and 3628800 for 10.

Abigail

Not to be a stickler, but it's not exponential growth. It's worse than that. For instance, 2**4 = 16, but 4! = 24. Choose any base j, and there's a number n such that j**n < n!. Of course, this only strenghens your point...:).

thor

Yes I know. That's why I like Randal's solution better. :-)

I thought I already provided this answer myself.

However, this does not address the capture-groups issue I mentioned in my question: if X, Y and Z all had capture groups, obtaining their values (and knowing which regexp each comes from) would require some funky code that I need to avoid.

Let me clarify my problem: the issue is not how to build a matching regexp, but how to keep the capture groups reasonable. The reason for this is that X Y Z would be build from regexps entered by the program users, who would also provide a result pattern, possibly containing $1 $2,... So I need the correspondence between the capture groups in the input regexps and the vars to be easy to describe.

#!/usr/bin/perl

use strict;
use warnings;

while (<DATA>) {
    chomp;

    print "$_: ", /^(?{ %choices = map {;"\Q$_" => 1} qw !X Y Z! })
                   (?: (?!)?  # Will never match, but keeps perl from 
+whining.
                       ((??{ keys %choices ? join "|" => keys %choices
                                           : "(?!)" }))
                       (?{ delete $choices {$1} }))+
                       (?(?{ keys %choices })(?!)|)$/x ? "ok\n" : "not
+ ok\n";
}

__DATA__
XYZ
ZYX
ZXY
XY
ZYYX
ABC


XYZ: ok
ZYX: ok
ZXY: ok
XY: not ok
ZYYX: not ok
ABC: not ok
[download]

Abigail

Why are you matching HTML with regexes? It's dangerous and fraught with peril, as well as being impossible to maintain or get right. Why not use something like, oh, HTML::Parser and have it deal with the problem of how to figure out what has way and you just ask it "Does tag ABC have attributes X, Y, and Z?"

Or ... attack the problem another way. Either these pages are static or they're not. If they are, then read them by hand. No matter how many you have, so long as they don't change, you'll finish, eventually. (A very large amount and q.v. solution #1.)

If they're generated in some fashion, then don't examine the output, examine the generator! A quick code review with a colleague and a whiteboard will quickly tell you if you're double-generating attributes. Now, if the code is dense and impenetrable, that's a good reason to rewrite it, and in the process guarantee that this issue is a non-starter.

Now, you might have issues with the idea of HTML being embedded in the code. Get it out and use templates. HTML doesn't belong in code, and vice-versa.

Of course, this entire discussion begs the question - why aren't you using CSS?

I thought I would get one of these, I should have answered all these in my initial posting... just it is long to explain and I'm too lazy.

> Why are you matching HTML with regexes?

Because I'm only interested in very small parts of the file, and by hard experience I've learned this is the fastest way.

Background information:

Well, I have to admit that my question was a Perl Regexp question, but not a Perl question. The problem at hand is coding for Apache Jakarta JMeter, a Java load/performance testing application. There are several situations in which we need to analyze HTML, but it's never the whole thing, but just small bits of it. For example obtaining values in a particular hidden field to pass in a later request, or obtaining the URLs of embedded elements (images, CSSs, etc.) to download them too.

Hope this answers your question on why we need to examine the output and not the generator.

As for not doing the wrong thing upon oocurence of double-attributes, I'm not too worried about that -- I currently live happily with the (?:X|Y|Z){3} -- it's more of a "how would I do it?" question than a "how do I do it"?

Still, JMeter is a test tool, and it should help you detect problems in your code (most relevantly performance problems and problems that only happen under load). Code review, as you suggest, is another way -- a complementary one, not an alternative one.

> Why not use something like, oh, HTML::Parser ... ?

We have implemented three alternative solutions: one based on HtmlParser, one on JTidy, and a crappy one I wrote using regexps. I am aware that the later can never be formally correct, but it is currently the fastest of the three and, I'm proud to say, the most reliable in real-world situations so far.

Hope I've addressed all your relevant concerns.

Salut,

Jordi.