Description:
------------
We use PHP as command line version. Usually first the global php.ini (in
PREFIX/lib/php) is parsed and evaluated, then PHP looks for a local
php.ini in the directory of the php-file that will be executed to look
for options that may override the global options.

This can be used e.g. to enable register_globals for a certain user.

In php-5.1.6 the local php.ini isn't recognized or at least the options
in there aren't evaluated. This worked fine even in the command line
versions of older php releases (php4 or php 5.0.x).

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

It would be helpful to know what you are missing.

try the following steps:

Put register_globals=off in the global php.ini.
Put a local php.ini with register_globals=on into e.g. /test.
Save a script with

<?

phpinfo();

?>

as /test/script.php

Run the command line version of php like /usr/local/bin/php
/test/script.php.

phpinfo() will give you register_globals=off. It will also not show you
any other options you have put into the local php.ini like change of
extension dirs etc.
safe mode is off.

Works perfectly fine here.
Please run `php -i | grep "php\.ini"`.

But it doesn't work here and other users in the mailinglist have the
problem. pwd is the directory of the script.

php -i | grep php.ini
<tr><td class="e">Configuration File (php.ini) Path </td><td
class="v">/usr/local/php-5.1.6/lib/php.ini </td></tr>

Global php.ini defines register_globals=off, local php.ini defines
register_globals=on

php -i | grep register_globals
<tr><td class="e">register_globals</td><td class="v">Off</td><td
class="v">Off</td></tr>

So the options of the local php.ini haven't become effective.

The is no ZendOptimizer, Ioncube or anything like loaded.

You are using CGI instead of CLI.

I never said that I'm using CLI. I said "command line version", not
"command line interface". However, while the problem may not exist in
the CLI version, it exists in the CGI version. So I hope someone can fix
it.

This is expected behaviour, CGI doesn't look for php.ini in the current
directory, only CLI does that.

Since when isn't this the expected behaviour? It worked for _all_
previous PHP releases and millions of ISPs are running PHP as CGI
version behind a CGIwrapper. Customers need to be able to change options
for their local scripts. And they cannot put ini_set() calls in all of
their scripts and sometimes they even cannot change the scripts due to
arising checksum-problems if they are using encoders/decoders like the
ZendOptimizer.
Through the local php.ini someone that needs register_globals=on can set
it like this, while it is off by default. Or someone might need his own
libraries that he wants to include as an extension so he needs to change
the extension_dir and so on. There definetely is a use for this feature
so why has someone removed it? And why isn't the removal mentioned in
the changelog if it has been done by intention?

We have had similiar issues.  We run php cgi via suexec in a shared
hosting enviroment.  When we were using php 4, users could simply place
a php.ini folder in the same folder as the script being ran, and php
would parse that ini file and load the settings in it.

When we upgraded to php5, that functionality was no longer there and we
have not found any reason why it is gone.  I believe it is related to
the same issue being reported here.  If there is anythig you would like
me to try to attempt to sort out this issue.

5.2.0 will fix this situation by reverting to pre 5.1.x behaviour, only
CLI will not look up in current working directory. Other sapis such as
CGI will look in the current dir when searching for php.ini.