[PATCH] PHP-cli ini search path

php.internals

Hannes Magnusson

19 years ago
Hi all Attached is a patch for the PHP-cli php.ini search path feature which fixes two things: a) php.ini from cwd was picked up on BSDs b) "resolves" to correct php-binary-location and picks up the php.ini file from there The php.ini-from-binary-location feature has never worked properly before on *nix except with /path/to/php :( Any objections? -Hannes

Edin Kadribasic

19 years ago
Looks good. Ini search path is very broken indeed. Edin On 23/04/2007, at 19.01, Hannes Magnusson wrote:

Stanislav Malyshev

19 years ago
Could you explain - why do you need to use VCWD there? Hannes Magnusson wrote:
> Hi all > > Attached is a patch for the PHP-cli php.ini search path feature which > fixes two things: > a) php.ini from cwd was picked up on BSDs > b) "resolves" to correct php-binary-location and picks up the php.ini > file from there > > The php.ini-from-binary-location feature has never worked properly > before on *nix except with /path/to/php :( > > Any objections? > > -Hannes >
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Hannes Magnusson

19 years ago
It fixes the bug on BSDs where the ini is picked up from cwd - and when you do "touch php && php -v" On 4/25/07, Stanislav Malyshev <stas@zend.com> wrote:

Stanislav Malyshev

19 years ago
How BSD is different from any other Unix? And as far as I see, tsrm_realpath uses getcwd anyway, so what's the difference? Hannes Magnusson wrote:
> It fixes the bug on BSDs where the ini is picked up from cwd - and > when you do "touch php && php -v" >
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Edin Kadribasic

19 years ago
Hi Stas, The problem is with the following scenario: Say your php cli is in /usr/bin/php and /usr/bin is in your path. You change dir to /tmp. Now issue php -v and watch where php looks up its php.ini. main()'s argv[0] will in this case be just "php" since we got called form the path. The code in main/php_ini.c will try to do a realpath() on "php" which will fail on Linux (since php does not exist in the current dir). On BSD it will return /tmp/php due to the fact that BSD realpath does not check for file existance. Then our code will basically do dirname on the result, which will result in php.ini path being set to /tmp in effect adding CWD in the php.ini search path which was definitely not what we wanted there. On Linux same thing will happened if you have any file named php in your CWD. So touch php && php -v will produce the exact same problem on Linux. Windows uses win32 api call designed to lookup the binary name and is not affected by this. Edin Stanislav Malyshev wrote: