How do you get s/// to look inside variables in the replacement string?

markkawika has asked for the wisdom of the Perl Monks concerning the following question:

I have a case where I'm taking user input and feeding it to perl code in the following format:

  $str =~ s/$match/$repl/;
[download]

where $str, $match, and $repl are strings fed to me by my user. Ignoring the security implications of this (I know there are plenty), I cannot get perl to recognize "\1" or "$1" sequences in the $repl variable.

For example, if $str contains "abc", $match contains "(a)(.)", and $repl contains "\2\1", $str ends up containing "\2\1c" instead of "bac", as intended.

Is there any way to force s/// to process this like I want?

Comment on How do you get s/// to look inside variables in the replacement string? Download Code

Replies are listed 'Best First'.
Re: How do you get s/// to look inside variables in the replacement string? by almut (Canon) on Nov 28, 2007 at 01:05 UTC
One way would be to use double eval: `#!/usr/bin/perl my $str = 'abc'; my $match = '(a)(.)'; my $repl = '$2$1'; $str =~ s/$match/"\"$repl\""/ee; print "$str\n"; # bac` [download]	[reply] [d/l]
Re^2: How do you get s/// to look inside variables in the replacement string? by markkawika (Monk) on Nov 28, 2007 at 01:40 UTC
Thanks, that does exactly what I need.	[reply]
Re: How do you get s/// to look inside variables in the replacement string? by graff (Chancellor) on Nov 28, 2007 at 01:40 UTC
Another way is a string eval: `$s="abc"; $m="(a)(.)"; $r=qw/$2$1/; print "eval: \$s =~ s/$m/$r/"; eval "\$s=~s/$m/$r/"; print "\nresult: $s\n";` [download] Handy rule of thumb for getting the escapes and interpolations right in string evals: if the string prints out looking like the expression that you want to execute, then you've got it right. As for security concerns, it's a question of who the users are... I don't mind doing this sort of thing in a command-line shell program, because the users already have the ability to do all sorts of damage with other shell commands, and the reason they have login shell access is that they are trusted to avoid doing damage. (They'll make mistakes, but usually that just means the eval will fail with some sort of error message.) In a web service, of course, you need to be very careful, and should avoid string evals based on user input altogether.	[reply] [d/l]