Re: end of line anchor in regex

[sh1tn]

Less efficient, still possible:

$text = join($1, grep(/[^hello]/, split(/(\n)/, $text)));

perlrequick, perlretut, split, grep, join.

[Anonymous Monk]

less efficient, less maintainable, with a warning, and with a pitfall: what if a word other than the word to be deleted is composed entirely of letters in the targeted word. e.g.:

perl -wMstrict -e "my $text = qq(start\nrats\n);
$text = join($1, grep(/[^start]/, split(/(\n)/, $text)));
print qq(o/p: \n);  print qq({$text})"
Use of uninitialized value in join or string at -e line 1.
o/p:
{

}

wouldn't it at least be better to say  grep($_ ne 'start', ... ) (although it still leaves the "Use of uninitialized value ..." problem, which i don't quite understand)?

[Anonymous Monk]

...although it still leaves the "Use of uninitialized value ..." problem, which i don't quite understand.

my confusion stemmed from my bemusement with an imagined connection between the (\n) expression in the split regex and the $1 capture variable in the join and the idea that $1 must contain a newline at that point.

then it occurred to me that the intervening grep regex would undefine all the capture variables and, since it had no capturing parentheses of its own, leave them that way.

but it goes beyond that.   apparently, "capturing" parentheses in a split regex don't actually capture (at least not to the capture variables), so $1 was never defined at any point.

perl -wMstrict -e "my @ra = split /(c)/, 'abcde';
print '$1 ', defined $1 ? 'defined' : 'undefined', qq( @ra)"
$1 undefined ab c de

[ikegami]

Captures in the split regex does have an effect, but setting $1 shouldn't be relied on. The effect of captures in the split regex is to return the captured data.

split(/\n/,   "hello\nworld")  ->  ("hello", "world")
split(/(\n)/, "hello\nworld")  ->  ("hello", "\n", "world")

I'd recommend

$text = join '',
        grep $_ ne "$word\n",
        split /(?<=\n)/,
        $text;

if you wanted to use split.