Re: argv and argc on cliphp

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/business=sniper@php.net&no_note=1&tax=0&currency_code=EUR