16 years ago by johannes@php.net — view source

unread

Hi,

now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:

With <=5.2 we allow

include_path = "c:\foo\bar"

and treat the backslash as regular character. It's documented that way
in http://de.php.net/manual/en/configuration.php example #1 and in
php.ini-recommended.

This was caused by the changes in the ini parser which are important,
but in my opinion this is a break where we should try to find a way to
keep the behavior, especially as it was in the "recommended" php.ini
file and other places before.

Pierre completely disagrees, I guess he'll answer to this mail and tell
why :-)

Opinions from others, a good proposal to keep the improved ini handling
and making this work? :-)

johannes

This message was sent using IMP, the Internet Messaging Program.

16 years ago by Pierre Joye — view source

unread

hi,

Hi,

now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:

With <=5.2 we allow

include_path = "c:\foo\bar"

Pierre completely disagrees, I guess he'll answer to this mail and tell
why :-)

Things is that we have expandable variables now (or env). I think that
having double quotes working like in php is a good and safe thing. It
could be too tricky (or pointless) to have to deal with two kind of
backslashes, depending on the context. Especially as (and Johannes
should have mentioned it in his mail) the fix is as easy than:

include_path=c:\foo\bar\

or

include_path="c:/foo/bar/"

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Pierre Joye — view source

unread

hi,

but now it's too late for such changes,
we have to put the old behavior back.

Even if it may mean drop the new ini parser and features?

I'm waiting Jani's anwer on that.

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Stanislav Malyshev — view source

unread

Hi!

Even if it may mean drop the new ini parser and features?

Which features require \ to be special character? Maybe we could change
them so they do not?

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Jani Taskinen — view source

unread

Pierre Joye kirjoitti:

hi,

but now it's too late for such changes,
we have to put the old behavior back.

Even if it may mean drop the new ini parser and features?

I'm waiting Jani's anwer on that.

"" allow using ini variables, that's basically with " the only that has to
work.. just ignore other escaping?

--Jani

16 years ago by Stan Vassilev | FM — view source

unread

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.

16 years ago by William A. Rowe — view source

unread

Stan Vassilev | FM wrote:

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.

+1

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.

"Nobody reads update guides or installation instructions"

...until it breaks :) It can be spelled out clearly enough. The user just
wants clear instruction or an easy hit on google.

16 years ago by Jani Taskinen — view source

unread

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

16 years ago by Antony Dovgal — view source

unread

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.

Did you actually read what Johannes said?
"c:\Documents\tony" is perfectly legal string in both cases.
But in 5.3 it means "c:\Documents<tab>ony" and this is THE problem.
No error messages, no explanation whatsoever.

--
Wbr,
Antony Dovgal

16 years ago by Pierre Joye — view source

unread

hi,

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.

Did you actually read what Johannes said?

Same about Jani's reply

"c:\Documents\tony" is perfectly legal string in both cases.
But in 5.3 it means "c:\Documents<tab>ony" and this is THE problem.
No error messages, no explanation whatsoever.

See my reply

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Stan Vassilev | FM — view source

unread

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.

Did you actually read what Johannes said?
"c:\Documents\tony" is perfectly legal string in both cases.
But in 5.3 it means "c:\Documents<tab>ony" and this is THE problem.
No error messages, no explanation whatsoever.

Hi,

I read it. \D in the same string isn't a legal escaped combination and this
is where the user will be warned. Most paths are like this and this is
enough information for the user to receive an error with a link to the
changes described.

Furthermore, since when is INI compatibility a feature of PHP. I've never
considered I can simply upgrade my PHP and paste the old INI and run like
that with no tests whatsoever.

Regards,
Stan Vassilev

16 years ago by Antony Dovgal — view source

unread

I read it. \D in the same string isn't a legal escaped combination and this
is where the user will be warned.

Nope. This is perfectly legal, too.

php -r 'var_dump("\W\H\A\T?");'

string(9) "\W\H\A\T?"

--
Wbr,
Antony Dovgal

16 years ago by Stan Vassilev | FM — view source

unread

I read it. \D in the same string isn't a legal escaped combination and
this is where the user will be warned.

Nope. This is perfectly legal, too.

php -r 'var_dump("\W\H\A\T?");'

string(9) "\W\H\A\T?"

Hi,

If you'll treat the INI parsing exactly as a string literal in PHP code,
there's no much to be done.

Your proposal is to keep a completely separate method for parsing (the
current one), which also doesn't allow quote as a character (there's no way
to escape it).

My proposal is to have a proper subset of the PHP string literal parsing,
with the additional feature of warning when a user has apparently used the
slash in a way he may not have intended. You wouldn't really escape your
path like this, would you:

c:\Documents\toby

instead you'd go for:

c:\Documents\toby --OR--- c:/Documents/toby

Furthermore, parameters which specify pathnames can check for tabs (\t),
newlines (\n, \r) and null (\0) and warn the user for a possible mistake, we
don't have an actual scenario where a pathname contains tab or a newline,
now do we.

The upside of all this is:

consistent handling of PHP.ini, other INI-s, and PHP string literals
all those extra checks can be removed in PHP 6 or 7 after the changes
"sink in" into the userbase and it becomes common knowledge that backslash
needs to be escaped.

Regards, Stan Vassilev

16 years ago by Stanislav Malyshev — view source

unread

Hi!

My proposal is to have a proper subset of the PHP string literal
parsing, with the additional feature of warning when a user has

What for? Who would EVER need to have tab or newline in the path? Who
this feature - recognizing \n and \r and \t in paths - would serve, what
use case do you have for it?

instead you'd go for:

c:\Documents\toby --OR--- c:/Documents/toby

I'd go for copy-pasting windows paths and not having to hand-edit them.
Why should I? How it would make my life with PHP better?

Furthermore, parameters which specify pathnames can check for tabs (\t),
newlines (\n, \r) and null (\0) and warn the user for a possible
mistake, we don't have an actual scenario where a pathname contains tab
or a newline, now do we.

Why warn if we know what the right thing to do is? There's no chance
anybody has \n in path - or, for that matter, I have yet to see anybody
needing \n in ANY ini value. If you do, you probably are severely
misusing INI anyway. Why warn users about a bug (and yes, it is a bug -
anything that works contrary to what user needs is) - instead of just
fixing it?

The upside of all this is:

consistent handling of PHP.ini, other INI-s, and PHP string literals

Another hilarious abuse of "consistency". There's no any reason to treat
different things the same for the sake of imaginary "consistency".
php.ini and php code are different things, and should work according to
their use cases, and not according to imaginary "consistency" concerns.

all those extra checks can be removed in PHP 6 or 7 after the changes
"sink in" into the userbase and it becomes common knowledge that
backslash needs to be escaped.

Escaping backslashes in INI files is stupid. Forcing users to do stupid
work for "consistency" sake is double stupid.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Stanislav Malyshev — view source

unread

Hi!

Furthermore, since when is INI compatibility a feature of PHP. I've

Since forever?

never considered I can simply upgrade my PHP and paste the old INI and
run like that with no tests whatsoever.

That's natural expectation. Unnatural is to have to reconfigure your
system with each upgrade - because developers love to play with things
and couldn't care less for lowly users. I don't like this approach.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Jani Taskinen — view source

unread

Stanislav Malyshev wrote:

Hi!

Furthermore, since when is INI compatibility a feature of PHP. I've

Since forever?

never considered I can simply upgrade my PHP and paste the old INI and
run like that with no tests whatsoever.

That's natural expectation. Unnatural is to have to reconfigure your
system with each upgrade - because developers love to play with things
and couldn't care less for lowly users. I don't like this approach.

As usual, you ignore all that is told you. In this particular case
someone cared too much about "lowly users" and fixed a bug. Sorry for that.

Since you have (as usual) already made you mind, why don't you go and do
the damage to the code and stfu already? And you don't really need to
reply to every single fucking email that is sent about some issue...
I get enough spam already without yours added to the pile.

--Jani

16 years ago by Stanislav Malyshev — view source

unread

Hi!

I don't think something allowed and documented can be just remove
without considering the consequences. It worked and did what it was
intended to do, why we need to drop it?
If people actually have configs that would stop working in 5.3 and it
wouldn't be good for anybody. In windows, because of spaces, a lot of
people would have include_path with quotes, and also most of them use ,
because they just copy-paste these paths.
I'm also not sure how you'd have these people fix it. Say you have path
like: "c:\Documents and Settings\John Doe\My Documents\PHP Projects\Cool
Site Project\include" - you'd have everybody to manually scan each such
string and replace \ with /? Or just drop final ?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Pierre Joye — view source

unread

hi,

Hi!

I don't think something allowed and documented can be just remove without
considering the consequences. It worked and did what it was intended to do,
why we need to drop it?
If people actually have configs that would stop working in 5.3 and it
wouldn't be good for anybody. In windows, because of spaces, a lot of people
would have include_path with quotes, and also most of them use , because
they just copy-paste these paths.
I'm also not sure how you'd have these people fix it. Say you have path
like: "c:\Documents and Settings\John Doe\My Documents\PHP Projects\Cool
Site Project\include" - you'd have everybody to manually scan each such
string and replace \ with /? Or just drop final ?

Or simply remove the double quotes.

include_path=C:\Users\pierre\Documents\Digsby Logs

works just fine.

I think we are making a big problem of a non issue. This issue is easy
to catch and fix. If a problem occurs in an app, it will be visible
very quickly, like for missing extensions or wrong include_path.

Cheers,

Pierre
http://blog.thepimp.net | http://www.libgd.org

16 years ago by Stanislav Malyshev — view source

unread

Hi!

Or simply remove the double quotes.

include_path=C:\Users\pierre\Documents\Digsby Logs

works just fine.

I was under impression it doesn't always work, looking at the parser
space is not in VALUE_CHARS, also single quote and () (which can be used
by Windows in directory names) isn't. I'll check that.

I think we are making a big problem of a non issue. This issue is easy
to catch and fix. If a problem occurs in an app, it will be visible
very quickly, like for missing extensions or wrong include_path.

That's not exactly what people are looking for when they upgrade. I.e.
when you app stops working you don't exactly expect somebody yanked
include path from under your application. Of course you can find it, if
you look hard enough, but it'd be nice to avoid such "surprises" if
possible.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Scott MacVicar — view source

unread

I agree, users will notice quickly enough and the previous behaviour
doesn't match that of PHP.

If we provide an uprade information popup at the end of the Windows
installer it might help.

Scott

hi,

On Thu, Sep 4, 2008 at 11:08 PM, Stanislav Malyshev stas@zend.com
wrote:

Hi!

I don't think something allowed and documented can be just remove
without
considering the consequences. It worked and did what it was
intended to do,
why we need to drop it?
If people actually have configs that would stop working in 5.3 and it
wouldn't be good for anybody. In windows, because of spaces, a lot
of people
would have include_path with quotes, and also most of them use ,
because
they just copy-paste these paths.
I'm also not sure how you'd have these people fix it. Say you have
path
like: "c:\Documents and Settings\John Doe\My Documents\PHP Projects
\Cool
Site Project\include" - you'd have everybody to manually scan each
such
string and replace \ with /? Or just drop final ?

Or simply remove the double quotes.

include_path=C:\Users\pierre\Documents\Digsby Logs

works just fine.

I think we are making a big problem of a non issue. This issue is easy
to catch and fix. If a problem occurs in an app, it will be visible
very quickly, like for missing extensions or wrong include_path.

Cheers,

Pierre
http://blog.thepimp.net | http://www.libgd.org

16 years ago by Stanislav Malyshev — view source

unread

Hi!

Attached is the patch that does the following for php.ini parser:

{LETTER} is literal inside "" now, whatever the letter is
" is " inside "", with exception of:
foo="bar"{NEWLINE} is parsed as bar\ - i.e. \ is allowed before
closing " but only if the line ends there (otherwise it's impossible to
know what the intent was).

That should make Windows paths work just fine (unless you have some
really weird ones that I didn't think about) with double quotes.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Pierre Joye — view source

unread

hi,

Hi!

Attached is the patch that does the following for php.ini parser:

{LETTER} is literal inside "" now, whatever the letter is

" is " inside "", with exception of:

foo="bar"{NEWLINE} is parsed as bar\ - i.e. \ is allowed before closing
" but only if the line ends there (otherwise it's impossible to know what
the intent was).

That should make Windows paths work just fine (unless you have some really
weird ones that I didn't think about) with double quotes.

That's exactly why I am reluctant to change what Jani did. It is
easier to deal with this minor breakage in 5.3.0 and then have a
consistent and clean configuration system. Continuing to add some
exceptions while hoping that "no weird things" are used is a bad idea
as well. There is a kind of breakage, but it is obvious and will be
directly seen as either the include_path will be incomplete (app
fails), an extension will be not be loaded, etc.

Jani even suggested to add fatal error. The lack of error messages
was one of the main arguments against this feature.

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Stanislav Malyshev — view source

unread

Hi!

That's exactly why I am reluctant to change what Jani did. It is
easier to deal with this minor breakage in 5.3.0 and then have a
consistent and clean configuration system. Continuing to add some
exceptions while hoping that "no weird things" are used is a bad idea

Do you see any problem with my patch? Any weird things?

Jani even suggested to add fatal error. The lack of error messages
was one of the main arguments against this feature.

No, the main argument is that it would break people's configs, and for
no good reason at all (nobody really needs \n's in their paths).

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Scott MacVicar — view source

unread

Stanislav Malyshev wrote:

Hi!

That's exactly why I am reluctant to change what Jani did. It is
easier to deal with this minor breakage in 5.3.0 and then have a
consistent and clean configuration system. Continuing to add some
exceptions while hoping that "no weird things" are used is a bad idea

Do you see any problem with my patch? Any weird things?

Jani even suggested to add fatal error. The lack of error messages
was one of the main arguments against this feature.

No, the main argument is that it would break people's configs, and for
no good reason at all (nobody really needs \n's in their paths).

This code is used in parse_ini_file() where it is possible that escapes
would be used legitimately, it's not all about paths.

Scott

16 years ago by Andras — view source

unread

Scott MacVicar wrote:

Stanislav Malyshev wrote:

Hi!

That's exactly why I am reluctant to change what Jani did. It is
easier to deal with this minor breakage in 5.3.0 and then have a
consistent and clean configuration system. Continuing to add some
exceptions while hoping that "no weird things" are used is a bad idea

Do you see any problem with my patch? Any weird things?

I don't really see anything wrong here, it's even a good idea.
But! Exceptions like this, that must be documented, are not logical
and may cause confusion.

Jani even suggested to add fatal error. The lack of error messages
was one of the main arguments against this feature.

No, the main argument is that it would break people's configs, and for
no good reason at all (nobody really needs \n's in their paths).

This code is used in parse_ini_file() where it is possible that escapes
would be used legitimately, it's not all about paths.

Scott

--

Andras

16 years ago by Jordi Boggiano — view source

unread

Stanislav Malyshev wrote:

No, the main argument is that it would break people's configs, and for
no good reason at all (nobody really needs \n's in their paths).

This code is used in parse_ini_file() where it is possible that escapes
would be used legitimately, it's not all about paths.

This means that not only php.ini will fail - although that is indeed
easy to notice - but also any application using ini files might break
in a much less obvious manner, right ? It's something that might need
to be taken into account.

16 years ago by Lukas Kahwe Smith — view source

unread

On Sat, Sep 6, 2008 at 2:15 AM, Scott MacVicar scott@macvicar.net
wrote:

Stanislav Malyshev wrote:

No, the main argument is that it would break people's configs, and
for
no good reason at all (nobody really needs \n's in their paths).

This code is used in parse_ini_file() where it is possible that
escapes
would be used legitimately, it's not all about paths.

This means that not only php.ini will fail - although that is indeed
easy to notice - but also any application using ini files might break
in a much less obvious manner, right ? It's something that might need
to be taken into account.

Seems to me like we should consider delaying this fix to 6.0. I agree
with Pierre that its probably not a good idea to introduce special
handling here and there.

As for the error handling, Pierre mentioned that Jani did some tweaks
there too. Could someone explain to me what kind of error handling is
out into place? If we throw a nice error message for all cases where
someone is using \t, \n etc incorrectly inside a php.ini, I think it
will not be such a big deal at upgrade time. But still it seems like
something we might want to hold off until 6.0, considering that the
bug that was fixed did not affect that many users (just a guess).

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

16 years ago by Stanislav Malyshev — view source

unread

Hi!

As for the error handling, Pierre mentioned that Jani did some tweaks
there too. Could someone explain to me what kind of error handling is
out into place? If we throw a nice error message for all cases where
someone is using \t, \n etc incorrectly inside a php.ini, I think it

I have changed the code already so \LETTER is not recognized in php.ini,
as it was in 5.2. I do not see any reason for using \n inside php.ini
(as far as I understand, in very unlikely case you ever need linefeed -
you've got the real one inside "") but there are very real cases where
\n can be in windows pathes.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Hannes Magnusson — view source

unread

Johannes Schlüter kirjoitti:

Hi,

now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:

With <=5.2 we allow

include_path = "c:\foo\bar"

That SHOULD cause a syntax error of course. If it doesn't,
it's the bug to fix. Allowing " was a bug that was fixed to begin with.
If that causes a syntax error, it's quite easy to catch and fix by people
upgrading to 5.3..

php.ini-recommended, 5.3:
;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: "/path1:/path2"
;include_path = ".:/php/includes"
;
; Windows: "\path1;\path2"
;include_path = ".;c:\php\includes"

As you can see, Windows users are explicitly told to use foo\bar
inside double quotes.
This has been like this for years and is also documented in the manual.

It looks to me that the old behavior was very intentional, logical or not.

-Hannes

16 years ago by Jani Taskinen — view source

unread

Hannes Magnusson wrote:

Johannes Schlüter kirjoitti:

Hi,

now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:

With <=5.2 we allow

include_path = "c:\foo\bar"
That SHOULD cause a syntax error of course. If it doesn't,
it's the bug to fix. Allowing " was a bug that was fixed to begin with.
If that causes a syntax error, it's quite easy to catch and fix by people
upgrading to 5.3..

php.ini-recommended, 5.3:
;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: "/path1:/path2"
;include_path = ".:/php/includes"
;
; Windows: "\path1;\path2"
;include_path = ".;c:\php\includes"

As you can see, Windows users are explicitly told to use foo\bar
inside double quotes.
This has been like this for years and is also documented in the manual.

It looks to me that the old behavior was very intentional, logical or not.

Ini files are not documentation. And as / works also for winblows, that
should be used JUST for the sake of consistency anyway..

Anyway, the fix is quite easy: Only allow " and no other escapes. And
doing "foo" should cause a syntax error.

--Jani

16 years ago by Stanislav Malyshev — view source

unread

Hi!

Anyway, the fix is quite easy: Only allow " and no other escapes. And
doing "foo" should cause a syntax error.

Why? It's not like we don't know what the string "c:\foo\bar" is
supposed to mean - why shouldn't it just work?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

16 years ago by Jani Taskinen — view source

unread

Stanislav Malyshev wrote:

Hi!

Anyway, the fix is quite easy: Only allow " and no other escapes. And
doing "foo" should cause a syntax error.

Why? It's not like we don't know what the string "c:\foo\bar" is
supposed to mean - why shouldn't it just work?

Feel free to fix it.

I'm not going to do anything about it since in my opinion, there is no
problem to fix.

--Jani

ini-parsing, double quotes, windows in 5.3

Cheers,

Cheers,

Cheers,

php -r 'var_dump("\W\H\A\T?");'

php -r 'var_dump("\W\H\A\T?");'

Escaping backslashes in INI files is stupid. Forcing users to do stupid work for "consistency" sake is double stupid.

That's natural expectation. Unnatural is to have to reconfigure your system with each upgrade - because developers love to play with things and couldn't care less for lowly users. I don't like this approach.

Cheers,

That's not exactly what people are looking for when they upgrade. I.e. when you app stops working you don't exactly expect somebody yanked include path from under your application. Of course you can find it, if you look hard enough, but it'd be nice to avoid such "surprises" if possible.

Cheers,

That should make Windows paths work just fine (unless you have some really weird ones that I didn't think about) with double quotes.

No, the main argument is that it would break people's configs, and for no good reason at all (nobody really needs \n's in their paths).

Why? It's not like we don't know what the string "c:\foo\bar" is supposed to mean - why shouldn't it just work?

Escaping backslashes in INI files is stupid. Forcing users to do stupid
work for "consistency" sake is double stupid.

That's natural expectation. Unnatural is to have to reconfigure your
system with each upgrade - because developers love to play with things
and couldn't care less for lowly users. I don't like this approach.

That's not exactly what people are looking for when they upgrade. I.e.
when you app stops working you don't exactly expect somebody yanked
include path from under your application. Of course you can find it, if
you look hard enough, but it'd be nice to avoid such "surprises" if
possible.

That should make Windows paths work just fine (unless you have some
really weird ones that I didn't think about) with double quotes.

No, the main argument is that it would break people's configs, and for
no good reason at all (nobody really needs \n's in their paths).

Why? It's not like we don't know what the string "c:\foo\bar" is
supposed to mean - why shouldn't it just work?