http://www.perlmonks.org?node_id=1061188


in reply to Re: Parsing and translating Perl Regexes
in thread Parsing and translating Perl Regexes

Thx,

I didn't redirect warn() b/c I didn't expect it to be used by the underlying C code.

And indeed your code doens't work! (unfortunately)

$log will be undefined ... the output you are getting is just directly written to STDERR.

Just try to change it before it's written, like lowercasing with lc().

> Is use re debug; output stable enough for automated parsing?

we'll see, some stuff isn't escaped (like EXACT <>> (42) to match ">") so hopefully the regexes can still match them by surrouding context.

Do I have a better choice? (well thats why I started this thread =)

Cheers Rolf

( addicted to the Perl Programming Language)

Replies are listed 'Best First'.
Re^3: Parsing and translating Perl Regexes
by kennethk (Abbot) on Nov 04, 2013 at 21:02 UTC
    And indeed your code doesn't work!
    Yeah, I caught that a little late. As penance I tried to track down a hook, but couldn't find one. And so I offer up a solution using a guard. It's more intimidating, but at least it auto-expires and allows fine-grained localization.
    use strict; use warnings; my $log = parse_regex( q#(\\.|["']|x)# ); print $log; warn "And STDERR is back\n"; sub parse_regex { my ($regex) = @_; # Catch and stash warnings my $guard = stderr_eater(my $parselog); # --- compile regex eval q{ use re 'debug'; qr/$regex/; }; return $parselog; } sub stderr_eater { package STDERR::Eater; open my $guard, '>&', STDERR; close STDERR; open STDERR, ">", \$_[0]; return bless \$guard; sub DESTROY { close STDERR; open STDERR, ">&", $_[0]; } }

    My first thought was YAPE::Regex. Actually my first thought was roll my own, but that's more of a reflection on my own poor choices. It looks like there's some reasonable robustness there, but was unsure if this fell into the "online analyzers which are easily fooled". It'll at least take care of the tokenizing for you.


    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

      Thanks! =)

      > I offer up a solution using a guard.

      I think you are a little too concerned about the redirection thing. I know it looks weird (at least it did the first time for me) but it's well documented in the perldocs.

      Direct hooks into the regex-engine OTOH would be nice...

      > "online analyzers which are easily fooled".

      many online solutions think PCRE means PCRE...

      > It'll at least take care of the tokenizing for you.

      actually there more levels of tracing-info which use re qw/Debug .../ may supply. (I still have to dig into perlreguts to understand it completely)

      I like the fact that Perl does the hard thing for me ... and I have this nagging feeling that only Perl can parse Perl... ;-)

      One may trust into specifications, but regarding Perl I think direct control is better. ¹

      At second thought translating to other engines is a very ambitious task, I think I should start with a simple beautifier which translates "line-noise" to a '/x'-option multiline expression.

      Ok YAPE::Regex::Explain could possibly be patched for this.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

      ¹) kind of quoting a big administrator ;-)