[PHP-DEV] Bug #20887 (Two separate issues)
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
Re: [PHP-DEV] Bug #20887 (Two separate issues)
Hi, 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 original report goes: If /php.ini exists, that one is used no matter what PHPRC env is set or compiled in when starting up apache from a SysV script. Is it a bug in php, or could it be the Mandrake Linux 9.0 system? 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. My patch would give the accurate location of the binary being executed since it doesn't rely on argv[0]. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20887 (Two separate issues)
??? The original report goes: If /php.ini exists, that one is used no matter what PHPRC env is set or compiled in when starting up apache from a SysV script. Is it a bug in php, or could it be the Mandrake Linux 9.0 system? My bad, the fact does remain however, that there is a command line issue. 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. My patch would give the accurate location of the binary being executed since it doesn't rely on argv[0]. Once again, my bad... When I tested your patch on my system I forgot about the fact that the php found in the path would be my copy of 4.2.3 and would therefore not have your patch! Whoops... :) I retested with sapi/cli/php put into the path and lo-and-behold: open(/usr/local/bin//php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/bin//php.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php.ini, O_RDONLY) = 3 Exactly the right behavior! +1 your patch. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20887 (Two separate issues)
Note that the patche is still incomplete because it dismisses many *nix OS out there other than SunOS, Linux, FreeBSD, OpenBSD and NetBSD. Moriyoshi Sara Golemon [EMAIL PROTECTED] wrote: ??? The original report goes: If /php.ini exists, that one is used no matter what PHPRC env is set or compiled in when starting up apache from a SysV script. Is it a bug in php, or could it be the Mandrake Linux 9.0 system? My bad, the fact does remain however, that there is a command line issue. 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. My patch would give the accurate location of the binary being executed since it doesn't rely on argv[0]. Once again, my bad... When I tested your patch on my system I forgot about the fact that the php found in the path would be my copy of 4.2.3 and would therefore not have your patch! Whoops... :) I retested with sapi/cli/php put into the path and lo-and-behold: open(/usr/local/bin//php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/bin//php.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php.ini, O_RDONLY) = 3 Exactly the right behavior! +1 your patch. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
