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
Looks good. Ini search path is very broken indeed.
Edin
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 thereThe php.ini-from-binary-location feature has never worked properly
before on *nix except with /path/to/php :(Any objections?
-Hannes
<binary_path_search.patch.txt
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 thereThe 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/
It fixes the bug on BSDs where the ini is picked up from cwd - and
when you do "touch php && php -v"
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 thereThe 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/
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/
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:
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"