Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40271
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sci.fi from 63.208.196.178 cause and error)
Message-ID: <48C04743.403@sci.fi>
Date: Thu, 04 Sep 2008 23:38:27 +0300
Reply-To: jani.taskinen@iki.fi
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Stan Vassilev | FM <sv_forums@fmethod.com>
CC: PHP Internals List <internals@lists.php.net>
References: <20080904190717.aaz97tz688oogc4c@horde.chinstrap.eu> <48C01A91.6010501@daylessday.org> <1F1F55D1526B4BA1999B314C72CF56A6@pc>
In-Reply-To: <1F1F55D1526B4BA1999B314C72CF56A6@pc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] ini-parsing, double quotes, windows in 5.3
From: jani.taskinen@sci.fi (Jani Taskinen)

Stan Vassilev | FM kirjoitti:
>> I have to agree, this kind of change would be very frustrating for 
>> Win32 users, even though the solution is that simple.
>>
>> Nobody reads update guides or installation instructions, they're used 
>> to write path like that and they'll continue to do it, so we'll have 
>> much more bug reports after the release if we keep it this way. Just 
>> try to imagine how much PHP installations will suddenly stop working 
>> after the upgrade.
>> I do agree that this syntax is actually correct and it should have 
>> been done this way since the very beginning, but now it's too late for 
>> such changes, we have to put the old behavior back.
> 
> I'm a Windows PHP user. It's never late for a change of that kind. 
> Upgrading your PHP installation is officially a Big Event, and tweakin 
> the ini is a one-time operation per upgrade, so I believe some people 
> may be overestimating the pain it will cause.
> 
> There won't be any bug reports, if the ini parser detects improper 
> backslash usage (i.e., using a backslash with a following character 
> which doesn't form correct escape combination) and stops with 
> informative and descriptive message explaining the parser changes.  Then 
> anyone who can read, will figure it out, and fix it.

This is not really necessary change. We could only allow escaping only for " 
which is propably the only thing you might need in certain cases.

I can't remember now what the bug was that this actually fixed (!) but there was 
one related to putting double quotes in ini values..

--Jani