Re: Re: Applying a RegEx in a variable

[Hofmator]

Well, your way of taking it aparts breaks much too easy, e.g. on

m#bla#
/bla\//
/bla/g # as you already mentioned
...

But why shouldn't you use eval (what you call 'requoting', a rather strange expression imho), that's what it is made for. Don't reinvent the wheel.

In the end, you are trying to parse Perl and as the saying goes only perl can parse Perl (or was it PERL can parse perl? :).

Being extremley cautious about the content of anything you eval, however, is a totally different issue ...

-- Hofmator

[ChOas]

let`s keep dangerous content of the eval out of this...

I want to eval the expression whilst retaining information on the special
RegEx vars ($1..n, $&,$`,$', etc, etc) It really SHOULD be possible

I`m actually very close to printing the regex to a file, run the file as a Perl
program, let it print the vars to another file, and read them back into the
parent.... Now that`s what I call desperation....

GreetZ!,

ChOas

print "profeth still\n" if /bird|devil/;

[Hofmator]

Well, you can always do it the qr// way (this is better anyway if you are using the same regex more than once). Or you can do it along these lines:

my $match;
eval "\$String =~ $RegEx"; \$match = \$&";
print $match;

The code executed within the eval has access to the variables outside - again it works the same way as if the evaluated code was in a code block of its own.

-- Hofmator

[George_Sherston]

Hm. Yes. Quite right.

@a = split(/\//,$RegEx);
$m = pop @a;
shift @a;
$s = join("/",@a);

Better?
On the other question, I don't think eval does it, because it doesn't return the dynamically scoped variables. What I meant by 'requoting' was the kind of thing abstracts suggested above (which is a fine solution if the problem allows it to work, but seemingly it doesn't). So I think there's no alternative to thuggery.

One of the one-hand-clapping paradoces of perl, as I understand it, is that it encourages us to do what we like with it, including the things it doesn't let us do. Perl lets you parse anything, even perl (or PERL)! Only perl allows something that isn't perl to parse perl! La lutte continue!

§ George Sherston

[Hofmator]

<some code>
Better?

Yes, it's better but it still breaks. Consider e.g. giving the modifiers in a different order (/mi instead of your /im), giving multiple modifiers (/ii is perfectly legal) using different delimiters (m!pattern!) and so on.

I'm not saying that it is impossible to parse this regex construct by hand - but why should want to do that? The eval solution always works - if $RegEx is a legal perl pattern matching operator and you can pass out anything with the construct I explained elsewhere in this thread.

Your solution restricts the number of possible patterns and the ways of providing them. The qr solution suffers from the same problems, only it is less restrictive. And the eval is slow but gives you the whole range of possible pattern matching constructs (even s/// would work) and more (which can become a problem/security concern).

To sum up, without knowing the problem better (where does the $RegEx come from, what should be achieved with it, ...) we cannot tell which solution to favour. And as always, TMTOWTDI :)

-- Hofmator

[George_Sherston]

Hmm. I agree. It really would be mad to proliferate if / else statements to deal with all the different permutations of modifiers!

Also agree with what you said earlier - eval is the way to go, but only if you don't need the dynamically scoped variables.

I wonder if future perl releases will allow variables as modifiers -

$modifier = 'i'   # or anything else
$string =~ /$regex/$modifier;

- that would make this problem (and others like it?) a lot easier.

§ George Sherston