Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » argv and argc on cliphp »

argv and argc on cliphp

php.internals

Stanislav Malyshev

22 years ago
Is there any reason that PHP5 CLI does not register argc and argv in _SERVER like PHP4 does? There are a number of scripts that depend on it and just adding one more unnecessary incompatibility between PHP4 and PHP5. What is the problem with argv/argc being in _SERVER?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.109

Alan Knowles

22 years ago
Stanislav - looks like andrei changed it - you better cc his private mail as I dont think he reads internals often. Regards Alan Stanislav Malyshev wrote:

Rasmus Lerdorf

22 years ago
Andrei and I discussed this change and at the conceptual level at least $_SERVER should be populated with argc and argv if variables_order includes "S". If you have specifically configured your system to not create $_SERVER, then of course it shouldn't be there. The change was to always make argc and argv available in the CLI version regardless of the variables_order setting. As in, the CLI version will now always populate the global $argc and $argv variables. So, if you have "S" in your variables_order and you are not seeing $_SERVER['argc'] and $_SERVER['argv'] populated then something got messed up along the way. It should definitely be there. -Rasmus On Fri, 3 Oct 2003, Alan Knowles wrote:

Greg MacLellan

22 years ago
Rasmus Lerdorf wrote:
> Andrei and I discussed this change and at the conceptual level at least > $_SERVER should be populated with argc and argv if variables_order > includes "S". If you have specifically configured your system to not > create $_SERVER, then of course it shouldn't be there. The change was to > always make argc and argv available in the CLI version regardless of the > variables_order setting. As in, the CLI version will now always populate > the global $argc and $argv variables.
I don't really like the idea of populating two global variables, and I'm not sure where this is at right now, since I've only been following internals for the last few weeks. It's a good idea to be sure that argv and argc are always available (though, arguably, argc is not all that useful), but it would probably make more sense to put them in $_SERVER (and without the rest of the $_SERVER variables, if variables_order doesn't include "S"). You're not breaking code (since it can always use $_SERVER) and you're not introducing any globals (which goes along with the register_globals setting). Hopefully this discussion hasn't already taken place, but this is my two cents. ttyl, greg

Rasmus Lerdorf

22 years ago
On Fri, 3 Oct 2003, Greg MacLellan wrote:
> Rasmus Lerdorf wrote: > > Andrei and I discussed this change and at the conceptual level at least > > $_SERVER should be populated with argc and argv if variables_order > > includes "S". If you have specifically configured your system to not > > create $_SERVER, then of course it shouldn't be there. The change was to > > always make argc and argv available in the CLI version regardless of the > > variables_order setting. As in, the CLI version will now always populate > > the global $argc and $argv variables. > > I don't really like the idea of populating two global variables, and I'm > not sure where this is at right now, since I've only been following > internals for the last few weeks. It's a good idea to be sure that argv > and argc are always available (though, arguably, argc is not all that > useful), but it would probably make more sense to put them in $_SERVER > (and without the rest of the $_SERVER variables, if variables_order > doesn't include "S"). > > You're not breaking code (since it can always use $_SERVER) and you're > not introducing any globals (which goes along with the register_globals > setting).
Sure you are, you are creating the global $_SERVER which was specifically not enabled in your scenario. To me it is more consistent with every other language out there to make $argc and $argv available directly. -Rasmus

Zeev Suraski

22 years ago
> > I don't really like the idea of populating two global variables, and I'm > > not sure where this is at right now, since I've only been following > > internals for the last few weeks. It's a good idea to be sure that argv > > and argc are always available (though, arguably, argc is not all that > > useful), but it would probably make more sense to put them in $_SERVER > > (and without the rest of the $_SERVER variables, if variables_order > > doesn't include "S"). > > > > You're not breaking code (since it can always use $_SERVER) and you're > > not introducing any globals (which goes along with the register_globals > > setting). > >Sure you are, you are creating the global $_SERVER which was specifically >not enabled in your scenario.
I may be missing something, but that doesn't break any code. If you don't use it - it doesn't affect you. The chances of you using this variable for other purposes is slim to non existent. Why not always have it available there too, for the sake of people who are already getting used to living without globally registered variables? Zeev

Greg MacLellan

22 years ago
> > > You're not breaking code (since it can always use $_SERVER) and you're > > > not introducing any globals (which goes along with the
register_globals
> > > setting). > > > >Sure you are, you are creating the global $_SERVER which was specifically > >not enabled in your scenario. > > I may be missing something, but that doesn't break any code. If you don't > use it - it doesn't affect you. The chances of you using this variable
for
> other purposes is slim to non existent. Why not always have it available > there too, for the sake of people who are already getting used to living > without globally registered variables?
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. This has the double-edged effect of making it a standard to always use $_SERVER['argv'] for cli, and to discourage people from removing S from variables_order and using $_SERVER as their own variable name for something else. Making globals $argv and $argc always created is just cluttering the namespace even more, and (I think) breaks the idea of always putting variables into the superglobal $_* arrays. ttyl, greg

Rasmus Lerdorf

22 years ago
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. > > This has the double-edged effect of making it a standard to always use > $_SERVER['argv'] for cli, and to discourage people from removing S from > variables_order and using $_SERVER as their own variable name for something > else. > > Making globals $argv and $argc always created is just cluttering the > namespace even more, and (I think) breaks the idea of always putting > variables into the superglobal $_* arrays.
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. -Rasmus

Greg MacLellan

22 years ago
> > 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. 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?)? 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? ttyl, greg

Rasmus Lerdorf

22 years ago
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

Jani Taskinen

22 years ago
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

Zeev Suraski

22 years ago
At 05:18 07/10/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. > > > > This has the double-edged effect of making it a standard to always use > > $_SERVER['argv'] for cli, and to discourage people from removing S from > > variables_order and using $_SERVER as their own variable name for something > > else. > > > > Making globals $argv and $argc always created is just cluttering the > > namespace even more, and (I think) breaks the idea of always putting > > variables into the superglobal $_* arrays. > >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.
I think that making $_SERVER dependant on the settings of variables_order was wrong to begin with (I may have caused it to be that way in the first place, I don't remember, but all the same, it appears wrong). All the tricks with variables_order/gpc_order were there to allow people to work around problems with register_globals. Linking them with the auto globals doesn't make any sense to me, and is the source of the wtf factor here to begin with. The only reason one may want not to populate the auto-globals is performance. I think that the cases where you would really like to disable one of those are rare. I think that our best bet is to always populate the auto globals, regardless of variables_order, and possibly provide means to explicitly turn them off for performance reasons. Zeev

Rasmus Lerdorf

22 years ago
On Tue, 7 Oct 2003, Zeev Suraski wrote:
> At 05:18 07/10/2003, Rasmus Lerdorf wrote: > >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. > > I think that making $_SERVER dependant on the settings of variables_order > was wrong to begin with (I may have caused it to be that way in the first > place, I don't remember, but all the same, it appears wrong). All the > tricks with variables_order/gpc_order were there to allow people to work > around problems with register_globals. Linking them with the auto globals > doesn't make any sense to me, and is the source of the wtf factor here to > begin with. > > The only reason one may want not to populate the auto-globals is > performance. I think that the cases where you would really like to disable > one of those are rare. I think that our best bet is to always populate the > auto globals, regardless of variables_order, and possibly provide means to > explicitly turn them off for performance reasons.
But the means to turn them off is variables_order. Being able to disable populating E and S can give a decent performance boost and for the most part you never need these. Having register_argc_argv being dependant on the variables_order setting is very confusing. If you specifically say you want to register argc/argv, then that is what should happen. -Rasmus

Stanislav Malyshev

22 years ago
RL>> Andrei and I discussed this change and at the conceptual level at least RL>> $_SERVER should be populated with argc and argv if variables_order RL>> includes "S". If you have specifically configured your system to not RL>> create $_SERVER, then of course it shouldn't be there. The change was to RL>> always make argc and argv available in the CLI version regardless of the RL>> variables_order setting. As in, the CLI version will now always populate RL>> the global $argc and $argv variables. What I see just now is that argc/argv is never getting into the _SERVER. No wonder, since the code in php_variables.c looks like: if (PG(register_globals) || SG(request_info).argc) { /* register argc/argv into EG(symbol_table) */ } else if (!SG(request_info).argc) { /* register argc/argv into track_vars_array */ } Either I am missing something or this code is meaningless - why should track_vars_array be populated only when argc equals to 0? Maybe non-zero argc was the intent?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.109