[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? Zeev At 17:15 02/03/2003, Marcus Börger wrote: At 11:19 02.03.2003, Zeev Suraski wrote: zeevSun Mar 2 05:19:17 2003 EDT Log: Add JIT initialization for _SERVER and _ENV (it's less important for the others, even though it should be fairly easy now too) argc/v foes no longer work for CLI for example you can no longer do: php run-tests.php directory Try: php run-tests.php tests/basic/012.phpt And we have a problem with $GLOBALS (try run-tests.php without my patch following this email) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
At 16:38 02.03.2003, Zeev Suraski wrote: Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? CLI overwrites register_argc_argv: zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); If i add register_long_arrays like this zend_alter_ini_entry(register_long_arrays, 21, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); all is fine. So the question is if we want $argc/$argv without register_long_arrays !? Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? That leads to $_COMMAND or $_CMD. To answer my question above: The above variable should be independant and its ini setting register_argc_argv should be independant from register_long_arrays. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
At 17:56 02/03/2003, Marcus Börger wrote: At 16:38 02.03.2003, Zeev Suraski wrote: Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? CLI overwrites register_argc_argv: zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); If i add register_long_arrays like this zend_alter_ini_entry(register_long_arrays, 21, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); all is fine. Yeah, but it's really not related. The source of the problem is that CLI makes PHP register global variables even though register_globals is off. We can work around this, as far as I can tell, by using the workaround below. So the question is if we want $argc/$argv without register_long_arrays !? Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? That leads to $_COMMAND or $_CMD. Didn't quite understand what you mean by that... To answer my question above: The above variable should be independant and its ini setting register_argc_argv should be independant from register_long_arrays. They have nothing to do with each other. The code currently fails because the engine doesn't expect the argc/argv globals to be required, because register_globals is off. Now, that the engine's smart enough not to process the server variables unless register_globals is on or _SERVER is being used, argc/argv are not created (they're created inside the routine that processes the server variables, which doesn't get called if register_globals is off and _SERVER is not being used). register_long_arrays really has nothing to do with this bug, you're just seeing the symptom of a bug that lies elsewhere... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? That leads to $_COMMAND or $_CMD. Didn't quite understand what you mean by that... I meant to have $_COMMAND['argc'] and $_COMMAND['argv'] and $_COMMAND['commandline'] as a place to store argc/argv and _SERVER only having a copy of them for BC. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
At 18:49 02.03.2003, Derick Rethans wrote: On Sun, 2 Mar 2003, Zeev Suraski wrote: Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? IMO they should not be registered when register_globals is off. That is why the test reads $_SERVER['argc'] and $_SERVER['argv'] when register globals is off. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
