Re: /g option not making s// find all matches

In the spirit of TIMTOWTDI, I offer another solution to my own problem.

After using the tips above to solve this problem, I moved on to the next one and, in the process, ran across a section of code employing a solution offered to another question I had asked here three years ago. And it turns out the solution I used in that case would have solved this current issue as well. Apparently, even the small fraction of perl that I know is too large to all fit into my brain at once.

The substitution line in my original example could become

  s/^ ~ .* /@{[  ${^MATCH} =~ tr#_#+#r  ]}/xp;
[download]

This separates the test for tilde from the substitution action (conceptually akin to tybalt89's solution and Eily's first one), yet keeps the whole thing inside a single s/// operator. And however much I admire the cleverness of \G (?! \A), its meaning is obscure even after its clockwork has been explained, whereas the above line is fairly easy to parse even if you've never encountered the @{[...]} idiom before.

For thoroughness, I plugged this s/// into AnomalousMonk's more comprehensive test suite above, and it passed all those as well.

Comment on Re: /g option not making s// find all matches Select or Download Code

Replies are listed 'Best First'.
Re^2: /g option not making s// find all matches by AnomalousMonk (Archbishop) on May 31, 2018 at 20:14 UTC
... keeps the whole thing inside a single s/// operator. The only thing I would say about this is that you're firing up the eval-uator behind the scenes, so `s/^ ~ .* /@{[ ${^MATCH} =~ tr#_#+#r ]}/xp;` is (I think; haven't tested it) exactly equivalent to `s/^ ~ .* / ${^MATCH} =~ tr#_#+#r /xpe;` That's an awful lot of moving parts for what seems a fairly simple match and transformation. Getting back to Eily's first solution and in particular to tybalt89's solution, I don't see a problem with something like (also untested): `while (<FILEHANDLE>) { tr/_/+/ if m{ \A ~ }xms; do_something_with_fixed_up_line($_); }` [download] Simple, clear, one-step fixup, do whatever you want with the line thereafter. Oh, and BTW: Please don't use `#` as a delimiter for regex expressions; I know we're talking TimToady here, but there's no need for perversity! Give a man a fish: `<%-{-{-{-<`	[reply] [d/l] [select]
Re^3: /g option not making s// find all matches by raygun (Scribe) on Jun 01, 2018 at 04:11 UTC
Simple, clear, one-step fixup Yes, and absolutely the solution I would use if my real-life problem matched this simplified example of looping through an array or input stream. My code is doing the opposite: siccing an array of regex substitutions on a single string. Thus each modification has to be containable in an s///. (I can handle special cases outside this array, but minimizing special cases is a goal.) Please don't use # as a delimiter for regex expressions Yeah, I get that it indicates a comment, but for simple, inline expressions such as that one (a whole six characters after the `tr`), I like it for how it visually stands out better than most characters within a typical regular expression, making it easy to find the boundaries of each element. In code I write, all comments are set off with plenty of whitespace, so the eye won't be tricked into thinking a comment is lurking in the middle of what otherwise looks like a line of code. ("@" also stands out in many terminal fonts, but that would be true perversity.)	[reply] [d/l]