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.