This is because preg_replace() runs addslashes() internally on the captured subpatterns before substrituting them into the replacement string. It didn't used to but a few people complained that it was really hard to pass $n to a function because of single and double-quote conflicts. To be frank, I'm not sure how to solve this problem adequately, one group of people want the addslashes() run, the other one doesn't.

how about creating either two different functions, or another
attribute to preg_replace, that you can set true/false to run
that add_slashes or not?

of course I meant addslashes()

Ah - I see - so what I'm seeing is actually a symptom of the basic issue that addslashes() is not a perfect reciprocal to putting addslashes-affected characters inside a string - i.e.:

<?php
// double-quoted strings
echo "\""; // produces "
echo "\\"; // produces \
// but
echo "\'"; // produces \'

// single-quoted strings
echo '\''; // produces '
echo '\\'; // produces \
// but
echo '\"'; // produces \"
?>

whereas in mysql:

select "\""; # produces "
select "\\"; # produces \
select "\'"; # produces '

and perl is yet again different (with strings in single-quotes anyway):

print "\""; # produces "
print "\\"; # produces \
print "\'"; # produces '

print '\''; # produces '
print '\\'; # produces \\
print '\"'; # produces "

I suppose backward compatibility would prevent this core behavior from being changed at this stage - it's just kinda screwy that both single-quoting and double-quoting of strings is a bit of a compromise in terms of slashed characters.

Perhaps instead of sending preg_replace carry-forward values through the entire addslashes routine, only " and \ could be returned as slashed, and users could stick with using double-quotes for strings within the (eval'd) replace string... that would prevent people from having to use a hack get it to work as expected.

Thanks,
Chuck

I could change it so that only " and \ are slashed. From what I remember about some of the complaints before addslashes behavior was implemented, people had security concerns about using some external vars as parts of eval strings. If the vars contained some quotes, some unexpected or dangerous code could be evaluated..

I use the phplib template functions and apparently that library uses the preg_replace routines as well. Whenever I try to put slash-quote data through this template library it gets stipslashes it seems.
The problem boils down to:

preg_replace("/key/", '\' \\\' \\\\\'', "replacekeyvalue");

which should yield:

replace' \' \\'value

but yields

replace' \' \'value

This used to work properly in 4.0.4, but now it seems I have to preparse user input, replace \' and \\ with something else, run preg_replace and repatch the \' and \\ values. This is unworkable!

I'd vote for a configuration variable to fix this. Something in line with magic_quotes_gpc and magic_quotes_sybase. Perhaps magic_quotes_pcre?

I have the same problem, but the nature of the material I'm 
working on makes it hard to simply strip offending chars 
from the stings before running preg_replace, which would be 
the easiest solution.

I vote for an additional pcre modifier to turn off magic 
quotes.

Bernie     :o)

before this problem is solved
use preg_replace_callback instead
it's a nice function
:)

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php