php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #10228 preg_replace with e modifier barfs on quotes
Submitted: 2001-04-07 18:35 UTC Modified: 2001-04-16 12:57 UTC
From: dbrewer at insightpd dot com Assigned: andrei (profile)
Status: Closed Package: Regexps related
PHP Version: 4.0.4 OS: windows 2000 SP1
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dbrewer at insightpd dot com
New email:
PHP Version: OS:

 

 [2001-04-07 18:35 UTC] dbrewer at insightpd dot com
I'm running PHP version 4.04, Windows NT 5.0 build 2195.

Using the "e" modifier with preg_replace is supposed to evaluate the replacement term prior to doing the replace. The problem is that it chokes with errors when the term to be evaluated contains quotes. 

Try using "e" to evaluate a PHP expression like: 

strtoupper("this phrase has spaces")

It gives an error:

Warning: Unexpected character in input: '\' (ASCII=92) state=1 in framework_func.php(15) : regexp code on line 1

Parse error: parse error in framework_func.php(15) : regexp code on line 1

Fatal error: Failed evaluating code: strtoupper(\"This phrase has spaces\") in framework_func.php on line 15

However, it WILL allow you to pass a string with no quotes, as long as it doesn't have spaces! As an example, I use this bit of code to to allow any term enclosed in curlies in a string to be evaluated as PHP:

preg_replace("/(\{)(.*?)(\})/e", "$2", $string);

If $string contains "{strtoupper(no_spaces)}", that term will be replaced with "NO_SPACES" upon execution of the preg_replace. So far so good.

But it fails with "{strtoupper(has spaces, no quotes)}" AND with "{strtoupper("has spaces and quotes")}. Of course, the latter is the way one would expect it to work, because it's valid PHP. 

I have hopes that the new function preg_replace_callback will allow me to work around this, but it seems as if the e modifier should allow you to evaluate ANY legal PHP fragment.

Sorry if this is already known or is not considered a bug.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-04-16 12:57 UTC] andrei@php.net
It seems to work, at least in the latest CVS.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Tue Oct 15 16:01:26 2019 UTC