Don't forget register_argv_argc php.ini directive. :)
--Jani
On Mon, 6 Oct 2003, Rasmus Lerdorf wrote:
>On Mon, 6 Oct 2003, Greg MacLellan wrote:
>> > > That was my argument. I was saying that instead of ALWAYS creating $argv
>> and
>> > > $argc, regardless of register_global status, it should ALWAYS create
>> > > $_SERVER['argv'] and $_SERVER['argc'], regardless of variables_order
>> > > setting.
>> >
>> > My big problem with this approach is that when variables_order does not
>> > include "S" then it seems inconsistent to have a partially populated
>> > $_SERVER array. If $_SERVER['argc'] is there, why aren't other normal
>> > $_SERVER variables available? The wtf factor is a little too high for my
>> > tastes.
>>
>> Hmm. I think that's my problem with the $argv/$argc method too. If
>> register_globals is off, why are globals getting created? If nothing else,
>> $_SERVER is one variable, $argv and $argc are two.
>
>I think you have the wrong idea of what register_globals means. Turning
>off register_globals does not mean that your global symbol table will
>suddenly be empty. There are plenty of variables registered in the global
>symbol table. register_globals guides whether user-defined variables are
>allowed to be created in the global symbol table. Having $argc/$argv in
>the global symbol table has nothing to do with register_globals. These
>variables are not named by the user. It also provides a nice symmetry
>with other languages that make argc/argv available this way.
>
>> Maybe this situation (where register_globals = off, and variables_order
>> doesn't contain 'S') should just generate a warning (though I'm not sure
>> where, in this context. Are there any other warnings at startup?)?
>
>Why? This is a perfectly valid config.
>
>> Another option would be to introduce a new superglobal, $_ARGV, only for
>> cli. IMO, argc is a bit antiquated anyways, as you can always use count(),
>> or even just foreach to go through. What may be an issue with this is that
>> $_ARGV would be a numerically-indexed array of the options, whereas the rest
>> of the superglobals are indexed by strings and all have meanings. It's also
>> a bit of a big change, and would mean that code written for this version
>> wouldn't be backwards-compatible. I'm not sure what the opinions of most
>> people are about making these sorts of changes.. maybe this is something
>> that could be introduced in PHP5?
>
>I guess you could argue that this is slightly cleaner, but the fact that
>it isn't backwards compatible makes the hassle factor too high for such a
>marginal cleanliness gain.
>
>-Rasmus
>
>
--
https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
