Doesn't work, but close. Solution:
s/[aeiou]/$&^"\x20"/gei
And you used $&? ouch!
s/([aeiou])/$1^"\x20"/gei
| [reply]
[d/l]
[select] |
Doesn't work, but close. Solution:
s/[aeiou]/$&^"\x20"/gei
Ouch! Just forgot that...
And you used $&? ouch!
s/([aeiou])/$1^"\x20"/gei
Well, this comes out too often!! Most of times it's about the performance penalty. As far as the latter goes, perlre specifies clearly that it's the same as that involved in capturing and using numbered vars. So it's not a problem for me if I have to use what I matched in any case. But then the other common objection is that it's just plainly ugly. Then I reply that beauty is in the eye of the beholder, and I don't find it to be quite that disturbing.
Granted: a variable name like $& is not that beautiful either, and IMHO it doesn't convey the psychological feeling of referring to what has been matched (Hopefully Perl6 will be better at this, but we still have to wait...) - as a side note there are situations, albeit not common ones, in which I'd like it to be $_: it's the topicalizer, and I say "match this, then substitute it with that (possibly depending on it)".
| [reply]
[d/l]
[select] |
As far as the latter goes, perlre specifies clearly that it's the same as that involved in capturing and using numbered vars.
That's only true if there are no other capture-less regexps in the program. Do you know where the OP intends to use your solution? When given two choices which are otherwise identical, one should pick the one that fails safe, the one that will cause no harm when the program is used in an unexpected manner.
Update: Added last sentence.
| [reply] |