The original complaint in bug 20887 was that the CLI version was picking up ini files in the wrong places. The patch I suggested last night does address that problem (albiet not correctly, see below).
The secondary "bug" which isn't really a bug is the complaint that CWD is included in the ini search path. While that *should* be suspended as the arguments for keeping "." in the search path for non-CLI sapis is valid. It really has nothing to do with the issues in bug 20887. The problem with the double forward slash is trivial and doesn't cause a real issue, the problem I mentioned above is with php being launched without a path (without even ./) If PHP is launched directly from the command line a la: mybox:~$ php -f myscript.php the system checks the PATH variable to find an executable and run PHP. When php_ini.c runs, it finds a 'binary_location' of "php" (inaccurate! Our CWD is ~ and ~/php does not exist) Neither my patch nor Moriyoshi's fixes this. If PHP is launched via a script's pound-bang declaration a la: mybox:/usr/local/bin$ ./myscript.php --- /usr/local/bin/myscript.php (filemode 755) #!php <?php echo 'foo'; ?> The shell (bash in the case of my tests) only looks for php in the CWD, If it finds one then it'll run and php_ini.c will show a binary_location of 'php' (correct in this instance, since /usr/local/bin/php does exist and is our executable). The current code in php_ini.c however, will try to look for the php.ini in 'php/php.ini' Ooops! (Both my patch and Moriyoshi's approach solves this one) In the former instance, ./php.ini shold not be scanned for CLI sapi, /usr/local/bin/php should be scanned instead except that we can't find it. (that's the whole discussion about not icluding '.' in the search path for CLI) In the latter instance, ./php.ini SHOULD be scanned for the CLI sapi as that is indeed where the binary is located. -Pollita -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
