From: ronlentjes at yahoo dot com dot au
Operating system: Fedora 11
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: Escaping curly braces produces backslash in output - Please
REVIEW this time
Description:
------------
*PLEASE REVIEW*
You closed this in the middle of me adding a correction to my
description. That was a bit annoying. Please have this reviewed with
others before just closing it like that. This is NOT an old issue as this
is a new suggestion for a way forward as customers are complaining!
Slamming to door on them will only infuriate them!
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
PHP Bugs
php.net | support | documentation | report a bug | advanced search |
search howto | statistics | login
go to bug id or search bugs for
Bug #49978 Escaping curly braces produces backslash in output - Suggested
Fix
Submitted: 23 Oct 11:03pm UTC Modified: 23 Oct 11:06pm UTC
From: ronlentjes at yahoo dot com dot au Assigned to:
Status: Bogus Category: Scripting Engine problem
Version: 5.3.0 OS: Linux Fedora 11
View/Vote Developer Edit Submission
Welcome! If you don't have a SVN account, you can't do anything here. You
can add a comment by following this link or if you reported this bug, you
can edit this bug over here.
SVN Username: SVN Password: Remember:
Quick Fix:
Status: Assign to:
Category:
Summary:
From: ronlentjes at yahoo dot com dot au
New email:
Version: OS:
New/Additional Comment:
[23 Oct 11:03pm UTC] ronlentjes at yahoo dot com dot au
Description:
------------
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to be
a bug as well.
I understand you made a change so that \ infront of any character not on
the list of escapes will print \ with that offending character. This is
good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you
that you gave no reasonable way ahead to fix old code and I think there
was miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea of
printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---------------
When $ is involved:
{ -> nothing (0 chars)
\{ goes to \{ (2 chars)
This is illogical. How to go to just one character { in these
cases. No I don't accept \$ this is missing the point.
Expected result:
----------------
Please add { to list of acceptable ESCAPE sequences.
\{ -> always got to single { character and stop the following $
processing.
Effectively, this ESCAPE WAS in old version. But you didn't realize it
when you added code to produce BAD ESCAPES. You forgot that \{ was an
escape in old version.
So just add it and document it.
That will solve all issues.
[23 Oct 11:06pm UTC] j...@php.net
You're couple of years too late. Still not a bug.
Correction:
Expected result:
----------------
Please add { to list of acceptable ESCAPE sequences.
\{ -> always go to single { character and *continue* the following $
processing as if { } were not present.
BTW. This is not couple year too late.
This is brand new suggestion.
I am only trying to help customers.
Please do not close this case so suddenly, I was just in middle of adding
more info about the correction as stated above.
The more you just slam dunk your customers, the more you obviously don't
care
about the hard work we do to help customers.
Cheers,
Ron Lentjes
LC CLS.
N.B.Please REVIEW this. Backwards compitibility is a very important issue
and can
keep from customers flaring up about hours and hours of rework which costs
them
enormous amounts of revenue.
You keep telling the to upgrade but your upgrades keep busting sites.
--
Edit bug report at http://bugs.php.net/?id=49980&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49980&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49980&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49980&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49980&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49980&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49980&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49980&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49980&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49980&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49980&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49980&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49980&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49980&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49980&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49980&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=49980&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49980&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49980&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49980&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49980&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49980&r=mysqlcfg
