in reply to Converting a stringified regexp back into a regexp

I think you want m{}s if your regex may have literal newlines. And if all the xism flags are on, there won't be a -.
  • Comment on Re: Converting a stringified regexp back into a regexp

Replies are listed 'Best First'.
Re^2: Converting a stringified regexp back into a regexp
by mirod (Canon) on Apr 07, 2005 at 16:58 UTC

    I am matching XML element names, so probably no newlines there. But indeed I have to make the second group optional:  m{^\(\?([xism]*)(?:-[xism]*)?:(.*)\)$}.

      How would you deal with 'g' or 'o' modifiers: i.e. m/blah/g

        I wouldn't! The regexp is used to match XML tag name in handler.

        For example this would replace headers by p tags in an XHTML file:

        XML::Twig->new( twig_handlers => { qr/^h\d?$/ => sub { $_->set_tag( +'p') }) ->parsefile( "foo.xhtml");

        The regexp is stringified then re-build, so in fact the /o is in effect, whether the user wants it or not. And the /g makes no sense, the regexp is not used in a loop, and either it matches and the handler is called, or it doesn't. In any case if there are several handlers of this type, as the stringified version is still used as a key to the hash, there is no garantee that they will always be tested in the same order (actually there is a guarantee under recent perls that they will be tested in different orders every time the code is run).

        Does this make sense?

        O.K., but what if you wanted to do this for another non-XML related reason? I solved it by creating a sub that looks for (?g) or (?o) or even (?go) and strips them out and then runs m/blah/g or m/blah/o or m/blah/go -- pretty klunky but it works. Is there a better way?