RE: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Andi Gutmans wrote: At 05:34 PM 12/9/2002 +0100, Marcus Börger wrote: At 14:52 09.12.2002, Mike Robinson wrote: Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson What do you want then? For historical reasons you will allow us only to introduce total new functionality and bug fixes? No more improvements that will have any influence on some working systems out there? Then i'll answer stay where you are and do not do any version upgrade evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) Excellent idea, Andi. +1 on phpsh, -1 on renaming CGI. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Sebastian Nohn wrote:
(B Jan Schneider schrieb:
(B
(BI know this thread is ridden to death but I want to add
(Bone argument for
(Bcompleteness: If the cgi's name will be changed,
(Bthousands of administrators
(Bneed to fix their servers. But if the cli's name will be
(Bchanged thousands
(Bof "end users" of php cli scripts will have to change the
(Bscripts' shebang line.
(B
(BI have no idea if there are more administrators who have
(Bto care about php
(Bcgi or users who use php cli. But at least the first
(Bgroup will have less
(Bproblems fixing the name change than the latter.
(B
(B
(B
(B PHP-CLI was experimental so far, so anyone who uses it has to be aware
(B of any changes that can happen. PHP-CGI is very far from being
(B experimental. I have no problem with all that renaming thing, but if we
(B rename the CGI-PHP to php-cgi we should do it with php5, because more
(B people will realize that a lot of things change between 4.x and 5.x.
(B For psychological numbering-reasons people don't see any change between
(B 4.2 and 4.3.
(B
(BI guess Jan is trying to say, people are using CGI binary for
(Bgeneral scripting. If they want to switch to CLI for general
(Bscripting, they have to rename binary to use CLI.
(B
(Bi.e. from "#!/usr/local/bin/php -q" to "#!/usr/local/bin/php-cli"
(B
(BBTW, people may want to add ini_set('implicit_flush','off);
(Bto all of their CLI scripts to prevent needless/redundant
(Bflushing anyway, though. (CLI flushes on every output by
(Bdefault not like CGI)
(B
(Be.g. ?php echo "Hello world\n" ? makes system flush output
(Btwice on char devices, once for block devices.
(B
(BAdding needless flushing is stupid, since flushing is rather
(Bexpensive as some of you know.
(B
(B--
(BYasuo Ohgaki
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
I know this thread is ridden to death but I want to add one argument for completeness: If the cgi's name will be changed, thousands of administrators need to fix their servers. But if the cli's name will be changed thousands of end users of php cli scripts will have to change the scripts' shebang line. I have no idea if there are more administrators who have to care about php cgi or users who use php cli. But at least the first group will have less problems fixing the name change than the latter. Just my 0.02 Euro. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Jan Schneider schrieb: I know this thread is ridden to death but I want to add one argument for completeness: If the cgi's name will be changed, thousands of administrators need to fix their servers. But if the cli's name will be changed thousands of end users of php cli scripts will have to change the scripts' shebang line. I have no idea if there are more administrators who have to care about php cgi or users who use php cli. But at least the first group will have less problems fixing the name change than the latter. PHP-CLI was experimental so far, so anyone who uses it has to be aware of any changes that can happen. PHP-CGI is very far from being experimental. I have no problem with all that renaming thing, but if we rename the CGI-PHP to php-cgi we should do it with php5, because more people will realize that a lot of things change between 4.x and 5.x. For psychological numbering-reasons people don't see any change between 4.2 and 4.3. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 10:28 10/12/2002, Sebastian Bergmann wrote: Zeev Suraski wrote: If we use this KISS approach, why the heck are we even considering this rename? 1.) Using 'php' to run a PHP script from the command-line sounds like the right choice of name (for the sapi/cli binary). Maybe, maybe not. I for one think it isn't, considering that PHP is a server-side language and the CLI falls outside the scope of the main project. phpsh or php-cli are much more descriptive names for me. But this discussion is beside the point, see below. 2.) Is keeping BC worth an unintuitive for the sapi/cli binary? Absolutely. No quantifyable gain (I consider phpsh equally intuitive). Does the rename of php to php-cgi for the sapi/cgi binary really cause so much trouble? It requires AFAICS the change of one line in the Apache configuration file Not sure what AFAICS translates to (lost you in the last 'S' in there), but that should already give you some indication that you're in the wrong direction. You have to THINK what the implications are, and you may or may not figure out all of them. Is it worth it? Absolutely not. Fact is, we could name the PHP-CGI phpfoo 5 years ago. People get used to it, set it up that way, and other than sounding weird in the beginning, it doesn't matter much at all. The key part is that 'people get used to it'. People are used to the PHP CGI being 'php'; People will get used to the PHP-CLI regardless of the name you call it. Deriving a conclusion from those two facts should be trivial. 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 11:00 10/12/2002, Edin Kadribasic wrote:
The CGI sapi was first renamed to php-cgi on Feb 28, and the change was
temporarily reverted for the 4.2.x release because CLI sapi was
considered experimental.
That maybe the way you see this. A handful of php-dev programmers may see
it in the same way, but then, even not all php-dev programmers see it that
way (me, for instance). As for the hundreds of thousands of users out
there, I'm willing to bet that the vast majority of them don't see it that
way at all, and frankly, that's what matters.
The reason for the name change was discussed on php-dev back then and it
had to do with the fact that most people felt that make install should
install CLI in ${PREFIX}/bin/php.
[snip]
Look, IMHO, it all boils down to the same simple points:
- No drawbacks to naming the PHP CLI as something different than PHP (well,
unless you count the gut feeling of people who 'feel make install should
install CLI in ${PREFIX}/bin/php', without really being able to say why).
- Considerable drawbacks to changing the PHP CGI name. You may argue that
the confusion this would cause is not as bad as I may think, but you cannot
argue that it won't cause confusion. I'm a fairly competent user, and it
still took me a few minutes to understand what was going on and
why. Suffice to say I came across less competent users.
P.S. I wish people were following this list more closely so that we don't
have to discuss same issues over and over again.
Unfortunately this is not an option for all of us at any given time.
I, for one, do wish that the developers here employed a more user-oriented
approach and less 'this should be changed cause it'll be cool/neat/Right'
approach. This would do a lot of good for PHP.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Zeev Suraski wrote: I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. I did not mean to offend you. Not sure what AFAICS translates to (lost you in the last 'S' in there) as far as I can see But either way, the fact that it was changed months ago is meaningless. I agree. What about installing the sapi/cli binary as php when a SAPI apart from sapi/cgi is chosen? Clearly someone who, let's say, builds his or her PHP --with-apxs has no need for a CGI binary. Or do I miss something? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Wed, 11 Dec 2002, Zeev Suraski wrote: Changing the name from php to php-cli will break BC: [root@saturnus php-4.2.3]# ./configure --enable-cli [root@saturnus php-4.2.3]# make [root@saturnus php-4.2.3]# sapi/cli/php -v 4.2.3 And the CGI is also called 'php' here, having two different binaries with both the name 'php' is even more confusing. So, you're actually proposing to break BC here Zeev? Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 14:00 11/12/2002, Derick Rethans wrote: On Wed, 11 Dec 2002, Zeev Suraski wrote: Changing the name from php to php-cli will break BC: [root@saturnus php-4.2.3]# ./configure --enable-cli [root@saturnus php-4.2.3]# make [root@saturnus php-4.2.3]# sapi/cli/php -v 4.2.3 And the CGI is also called 'php' here, having two different binaries with both the name 'php' is even more confusing. So, you're actually proposing to break BC here Zeev? Uhm, you know it's a twisted way of putting it, but if you want a yes/no answer, then yes. Breaking BC which is a few months old and used by a fragment of users vs. breaking BC that's 5-6 years old and used by hundreds of thousands? I know my pick. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 13:00 11-12-2002, Derick Rethans wrote: On Wed, 11 Dec 2002, Zeev Suraski wrote: Changing the name from php to php-cli will break BC: [root@saturnus php-4.2.3]# ./configure --enable-cli [root@saturnus php-4.2.3]# make [root@saturnus php-4.2.3]# sapi/cli/php -v 4.2.3 And the CGI is also called 'php' here, having two different binaries with both the name 'php' is even more confusing. Having the cli in /usr/local/bin when a running server points there, is not very healthy. Just overwriting the cgi binary with a newer version, should not be a problem. So, you're actually proposing to break BC here Zeev? This does not have to be an issue on *nix*. This is where configure options are for - providing people are really to lazy to type 1 alias in their profile environment to alias phpsh[1]/php-cli to the right binary. This is as much a one-time operation as changing a httpd.conf. For win32 binaries - this is a whole different issue and taking into account the stability of the isapi module, this is an area where it's used much. Just leave the cgi module in the root dir and move the cli to bin/ on win32 if you really wanna have the same names. [1] phpsh is not a good name, try running it as your shell... With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 13:39 11/12/2002, Sebastian Bergmann wrote: Zeev Suraski wrote: I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. I did not mean to offend you. I wasn't offended (seriously). Not sure what AFAICS translates to (lost you in the last 'S' in there) as far as I can see Ah, right :) But either way, the fact that it was changed months ago is meaningless. I agree. What about installing the sapi/cli binary as php when a SAPI apart from sapi/cgi is chosen? Clearly someone who, let's say, builds his or her PHP --with-apxs has no need for a CGI binary. Or do I miss something? I don't think that having choosing different names based on build flags is a good idea. It's another kind of recipe for confusion. Guys, fact is that it doesn't matter that much what this binary is called. We can call it bhb for all practical purposes (not that I'm suggesting that). People will get used to whatever it's named. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
[snip]
Look, IMHO, it all boils down to the same simple points:
- No drawbacks to naming the PHP CLI as something different than
PHP (well,
unless you count the gut feeling of people who 'feel make install
should
install CLI in ${PREFIX}/bin/php', without really being able to
say why).
- Considerable drawbacks to changing the PHP CGI name. You may
argue that
the confusion this would cause is not as bad as I may think, but
you cannot
argue that it won't cause confusion. I'm a fairly competent user,
and it
still took me a few minutes to understand what was going on and
why. Suffice to say I came across less competent users.
The big drawback for me is the BC issue of changing all the command
line scripts that contain #!/usr/bin/php in them. I still see no
sense in putting a CGI binary there. Configuring a web server for
running CGI involves manual copy of the PHP binary anyway.
P.S. I wish people were following this list more closely so that
we don't
have to discuss same issues over and over again.
Unfortunately this is not an option for all of us at any given
time.
I, for one, do wish that the developers here employed a more
user-oriented
approach and less 'this should be changed cause it'll be
cool/neat/Right'
approach. This would do a lot of good for PHP.
I don't claim to hold a monopoly on what is a user-oriented
approach. I'd sure like to think that the changes implemented are
for the good of the user. Not because they're cool/neat/Right.
I agree that most of development done in PHP is geared towards the
web. That's what I do for living as well. But in the past 3 years
and about a dozen or so rather large PHP solutions later, I see that
the command line scripting mustn't be neglected either. Why write
backend processes in language other than PHP? Once we have developed
all the classes/libraries for the web solution it is obvious that
the easiest way to implemet the rest of the system is to re-use
those in command line (often run from cron) PHP scripts. And from
what I hear from other development houses, my experiences are far
from unique.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: 11 December 2002 12:15 Guys, fact is that it doesn't matter that much what this binary is called. We can call it bhb for all practical purposes (not that I'm suggesting that). People will get used to whatever it's named. If it were me (which, of course, it isn't, but...), I'd leave the cgi as php and call the command-line version phpc. (Well, actually, if it were *just* me, I'd leave them both as php -- even on Windows -- and just make sure I had them in appropriate directories, but I'm extremely aware that real-world users are often not up to that kind of subtlety.) What I absolutely would *not* do is rename the cgi version to php-cgi whilst *simultaneously* introducing a new php with a different purpose. If I were going to do this, I'd want to do it in steps: 1 - cgi to php-cgi + introduce php-cli (so any installations still looking for php get a straight file not found); 2 - php-cli to php. As I'm pretty sure this isn't going to fly, let's go back to my first para...!! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 14:20 11/12/2002, Shane Caraveo wrote: 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. After hashing this a bit on IRC and thinking about it, I tend to think that this is the only solution that makes sense and bug the tiniest amount of people. It may be ugly from a technical standpoint, but frankly, who cares? A dozen or so developers who know and care about what goes on in cgi_main.c. With any other solution, either we screw up the huge CGI community, or we screw up the CLI community (the size of which is subject to debate, but for the sake of the argument, let's assume it's big). I'm +1 on remerging CLI back into CGI. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 14:02 11.12.2002, Zeev Suraski wrote: At 14:20 11/12/2002, Shane Caraveo wrote: 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. After hashing this a bit on IRC and thinking about it, I tend to think that this is the only solution that makes sense and bug the tiniest amount of people. It may be ugly from a technical standpoint, but frankly, who cares? A dozen or so developers who know and care about what goes on in cgi_main.c. With any other solution, either we screw up the huge CGI community, or we screw up the CLI community (the size of which is subject to debate, but for the sake of the argument, let's assume it's big). I'm +1 on remerging CLI back into CGI. Zeev This does not work since then you will have pcnt in cgi and such Also there are many differences in the source which would require a hughe amount of if-then-else. And isn't the fraction having problems with renaming CGI to php-cgi itself a very small group compared to the overall of user (only on win*)? And from my guesses in a short time the amount of users working with CLI will outweigh those heavily. (And as somebody mentioned already windows users are used to have problems with php until now. Only the 4.3 release will fix some trouble there.) So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
If we're voting now .. +1 for having CGI as PHP and renaming CLI -1 for having one exe all-in - Original Message - From: Edin Kadribasic [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Shane Caraveo [EMAIL PROTECTED]; Sebastian Bergmann [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 1:57 PM Subject: Re: [PHP-DEV] php.exe - php-cgi.exe So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
[imagine large quantities of quoted text here] On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. aolme too/aol [imagine large quantities of quoted text here] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
My opinion : Windows : CGI - php.exe CLI - php-cli.exe All other platforms : CLI - php CGI - php-cgi Why I think in this way. Many users use the cgi version under windows. Small percent of the *nix users use php as cgi. Most of the installations are libphp4.so . I know that it is not consistent but in this way it will hurt less people and satisfying those who use the CLI version (mostly if not only on *nix platforms) Andrey - Original Message - From: Wez Furlong [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Shane Caraveo [EMAIL PROTECTED]; Sebastian Bergmann [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 4:04 PM Subject: Re: [PHP-DEV] php.exe - php-cgi.exe [imagine large quantities of quoted text here] On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. aolme too/aol [imagine large quantities of quoted text here] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. .o/ --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 15:37 11/12/2002, Marcus Börger wrote: This does not work since then you will have pcnt in cgi and such I don't see how that is a problem. You can build --with-pcntl or not. Also there are many differences in the source which would require a hughe amount of if-then-else. That doesn't interest end users and isn't really a problem beyond the tiny scope of the very few php-dev developers who work on cgi_main.c. And isn't the fraction having problems with renaming CGI to php-cgi itself a very small group compared to the overall of user (only on win*)? Hmm no, it effects all CGI users, not just Windows one. There are a hell of a lot more CGI users than there are CLI users. And from my guesses in a short time the amount of users working with CLI will outweigh those heavily. (And as somebody mentioned already windows users are used to have problems with php until now. Only the 4.3 release will fix some trouble there.) I don't think this will ever happen. PHP in CLI mode is popular around php-dev, but it's tiny beyond php-dev (and maybe pear-dev). PHP CGI is huge. And no, PHP under Windows is rock solid as a CGI, so they're already used to having problems approach doesn't apply (it wouldn't have applied either way in my opinion, as having problems is not a reason to add another problem, but still). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Somehow it doesn't surprise me that the same people who wanted other BC-breaking changes (minus perhaps Wez) are in favour of this change as well. Just for the record, we never had a real vote on php-dev or any of the other forums, and I don't think we'll start now. php-dev is an open forum and we can all find people that will vote our way if we want to. We have to hash it until we reach something that everyone can live with, or stay with the way things are right now (as in the way PHP 4.2 is, where they're both 'php'). I'm having a very hard time living with the PHP-CGI change, and I find it very difficult to find any drawbacks to keeping the one integrated binary we used to have since 1998(*). Zeev (*) For the record, as a core developer who worked a lot on cgi_main.c I felt the cleanliness issue at least as much as the rest of you, and my gut feeling was that separation is a good idea too. Given the problems we're now bumping into, I changed my mind, and think I (and the rest of you) sinned in thinking about what's cool/neat/Right for us, the few, instead of what's good for the users. Luckily it's not yet too late to prevent that from happening. At 16:53 11/12/2002, Jani Taskinen wrote: On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. .o/ --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
And no, PHP under Windows is rock solid as a CGI, so they're already used to having problems approach doesn't apply (it wouldn't have applied either way in my opinion, as having problems is not a reason to add another problem, but still). Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Wed, 11 Dec 2002, Zeev Suraski wrote: Somehow it doesn't surprise me that the same people who wanted other BC-breaking changes (minus perhaps Wez) are in favour of this change as well. Just for the record, we never had a real vote on php-dev or any of the other forums, and I don't think we'll start now. php-dev is an open forum and we can all find people that will vote our way if we want to. We have to hash it until we reach something that everyone can live with, or stay with the way things are right now (as in the way PHP 4.2 is, where they're both 'php'). I'm having a very hard time living with the PHP-CGI change, and I find it very difficult to find any drawbacks to keeping the one integrated binary we used to have since 1998(*). Zeev (*) For the record, as a core developer who worked a lot on cgi_main.c I felt the cleanliness issue at least as much as the rest of you, and my gut feeling was that separation is a good idea too. Given the problems we're now bumping into, I changed my mind, and think I (and the rest of you) sinned in thinking about what's cool/neat/Right for us, the few, instead of what's good for the users. Luckily it's not yet too late to prevent that from happening. Just for the record, not that it counts much, but I totally agree with you. Couldn't have said it any better than that. Joao -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Just for the record, there is no fork() on Win32. I have little doubt Sterling meant the Win32 equivalent :). The only reason I felt this worth mentioning is that fork() on Unix is a relatively cheap operation, and an advantage unique to Unix. Some have posted here of service providers that host huge numbers of low volume websites using PHP in CGI mode. On Win32 you only have one choice - start a new php.exe instance on every request. This is an expensive operation - possibly even more expensive than the equivalent operation on Unix. On Unix you have another *potential* choice - load the php executable once and fork() on each request. The presence of fork() on Unix offers (at least in theory) a unique performance advantage over Win32. -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 7:50 AM Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. that sounds like a nice idea, but how would you know? Derick Perhaps by the presence of CGI environment vars? Sorry I'm amateur. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Just for the record, there is no fork() on Win32. I have little doubt Sterling meant the Win32 equivalent :). The only reason I felt this worth mentioning is that fork() on Unix is a relatively cheap operation, and an advantage unique to Unix. Some have posted here of service providers that host huge numbers of low volume websites using PHP in CGI mode. On Win32 you only have one choice - start a new php.exe instance on every request. This is an expensive operation - possibly even more expensive than the equivalent operation on Unix. On Unix you have another *potential* choice - load the php executable once and fork() on each request. The presence of fork() on Unix offers (at least in theory) a unique performance advantage over Win32. win32 supports fork in the way I was using it :), CGI semantics make your method of implementation impossible. CreateProcess() is the system call that is used. If you really wanted something similair you could call CreateThread() which would have the same effect. -Sterling -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 7:50 AM Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 19:50 09/12/2002, Marcus Börger wrote: At 19:46 09.12.2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. I am strongly against having two different names for the same thing on different machine targets. And Remeber: you can use the win executable by calling 'php' without '.exe' as well. I agree with Marcus. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 19:46 09/12/2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. Why? PHP as a shell is going to be used by only a fragment of the amount of users who use it as a CGI. In most senses, it's much more PHP than the CLI is. Even though the old version was being used as a shell, it was still quite clear that it is the CGI version. And it is quite clear that the CLI version is the one that's new... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 18:57 09/12/2002, John Coggeshall wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking Why when I look at phpsh I think Sushi... Is that good or bad? :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 18:27 09/12/2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I agree with Andi, except I'm a bit more decisive - I'm quite against the name change, and even more against the fact the CGI now relies in sapi/cgi instead of where it was. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 23:11 09/12/2002, Frank M. Kromann wrote: Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. These are good points. I think that's a bit like inventing problems and then trying to fix them. Let's keep it down to things we can determine relatively easily: - Nothing bad will happen if we name the new CLI with whatever kind of name - php-cli, phpsh, whatever - There WILL be some level of confusion if we rename the CGI binary If we use this KISS approach, why the heck are we even considering this rename? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 01:27 10/12/2002, John Coggeshall wrote: Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. As I already said, we should put this in the message created at the end of ./configure, in the release notes, in the news file, on the website, and perhaps send a mass e-mail to everyone whom has ever worked with PHP ;) Or, we could just avoid this rename which would save us all of this headache and have no drawbacks at all. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Leon Atkinson wrote: out on a limb Would it be a tragedy to name both the CLI and CGI versions php on UNIX and php.exe on Windows? Yes, it's a support nightmare. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Christoph Grottolo wrote: When installing a sapi for a web server i do it once and every time i update it i look if i have to change something in the setup - even file names. And before updating anything i test the stuff on a non production system. I hope (and I know) there's more evolution in php 4.3 than a senseless rename of php.exe on windows. I know you're right - but beeing right is not always the same as doing the right thing. Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. that sounds like a nice idea, but how would you know? Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Tue, 10 Dec 2002, Zeev Suraski wrote:
I think that's a bit like inventing problems and then trying to fix them.
Let's keep it down to things we can determine relatively easily:
- Nothing bad will happen if we name the new CLI with whatever kind of name
- php-cli, phpsh, whatever
- There WILL be some level of confusion if we rename the CGI binary
If we use this KISS approach, why the heck are we even considering this rename?
The CGI sapi was first renamed to php-cgi on Feb 28, and the change was
temporarily reverted for the 4.2.x release because CLI sapi was
considered experimental.
The reason for the name change was discussed on php-dev back then and it
had to do with the fact that most people felt that make install should
install CLI in ${PREFIX}/bin/php. The goal was to make the php interpreter
installed on as many machines as possible. And for the reasons of keeping
BC CLI sapi was named php so that existing scripts that have
#!/usr/bin/php shebang line would not have to be modified. For the same
reason CLI silently ignores some command line options (like -q and -C).
The next logical questions was what to do with the CGI sapi. It made very
little sense to make install it under the same name in some different
folder, so a decision was reached to rename it to php-cgi. make install
and cgi make very little sense anyway since the installer has no way of
knowing what's the correct location for the binary. Configuring a server
for execution of php as a cgi requires manual configuration anyway.
Windows file rename merely mirrored that of the unix build.
I'm still of the oppinion that we should leave things as they are in PHP
4.3.0-dev for the reasons stated.
Edin
P.S. I wish people were following this list more closely so that we don't
have to discuss same issues over and over again.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
I'm a little surprised that people from Zend is rather prefer to call php for CGI and php-cli for CLI. IMO, Zend products, such as Zend Encoder or Zend IDE, have more chance to sell if PHP is used as replacement for Perl or Python (or even Java). The name of command line interface may not affect sales of Zend products, though. Just my .02 -- Yasuo Ohgaki Zeev Suraski wrote: At 19:46 09/12/2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. Why? PHP as a shell is going to be used by only a fragment of the amount of users who use it as a CGI. In most senses, it's much more PHP than the CLI is. Even though the old version was being used as a shell, it was still quite clear that it is the CGI version. And it is quite clear that the CLI version is the one that's new... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Zeev Suraski wrote: If we use this KISS approach, why the heck are we even considering this rename? 1.) Using 'php' to run a PHP script from the command-line sounds like the right choice of name (for the sapi/cli binary). 2.) Is keeping BC worth an unintuitive for the sapi/cli binary? Does the rename of php to php-cgi for the sapi/cgi binary really cause so much trouble? It requires AFAICS the change of one line in the Apache configuration file Action application/x-httpd-php /php/php.exe to Action application/x-httpd-php /php/php-cgi.exe 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Tue, Dec 10, 2002 at 10:28:54AM +0100, Sebastian Bergmann wrote : 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! Because only if you start a release cycle and announce it properly people notice the NEWS which only happened now. More non-developers are getting aware of the upcommong 4.3 release and start to absorb the NEWS and question it. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. that sounds like a nice idea, but how would you know? Derick Maybe you can test the presence of CGI environment variables? I'm amateur... Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Markus Fischer wrote: More non-developers are getting aware of the upcommong 4.3 release and start to absorb the NEWS and question it. I do not count Zeev as a non-developer :) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Tue, Dec 10, 2002 at 03:38:09PM +0100, Sebastian Bergmann wrote : Markus Fischer wrote: More non-developers are getting aware of the upcommong 4.3 release and start to absorb the NEWS and question it. I do not count Zeev as a non-developer :) I was talking about Mr. Grottolo who started this thread. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
out on a limb Would it be a tragedy to name both the CLI and CGI versions php on UNIX and php.exe on Windows? Yes, it's a support nightmare. limb broken=yes / I defer to you. Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
P.S. I wish people were following this list more closely so that we don't have to discuss same issues over and over again. But it's fun to argue over the same things every six months! :P Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Esp. when some of us would love to see PHP5 start taking form :) John -Original Message- From: Leon Atkinson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 2:55 PM To: Edin Kadribasic Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe P.S. I wish people were following this list more closely so that we don't have to discuss same issues over and over again. But it's fun to argue over the same things every six months! :P Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 23:11 09/12/2002, Frank M. Kromann wrote: Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. These are good points. I think that's a bit like inventing problems and then trying to fix them. Let's keep it down to things we can determine relatively easily: - Nothing bad will happen if we name the new CLI with whatever kind of name - php-cli, phpsh, whatever - There WILL be some level of confusion if we rename the CGI binary If we use this KISS approach, why the heck are we even considering this rename? I happen to agree with Zeev here - I won't argue the potential of using PHP for GTK/command line scripting, however, currently that is not PHP's target audience, and in my opinion we should focus on our target audience first. Should PHP progress and become more popular outside the webspace (and cgi becomes less popular as well :), then it would make sense to rechange the name (perhaps for PHPv5), but at this point changing it to php-cgi just seems like solving a problem by creating a bigger one. -Sterling Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus Well, fortunately I never have time for qa, handling bugs, etc. etc. so I wont have to deal with the backlash that this name change **WILL** cause. I feel sorry for those who have the time to deal with it, as that will be about all they will deal with, rather than handling more important bugs and issues. Basicly, the namechange goes against several years of history in php, tons of documentation, general community knowledge, etc., and top it off with the fact that in reality, probably less than 1 percent of users use php as a command line language. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Mike Robinson wrote: Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Well no offence, but renaming the CGI executable is just plain wrong. The CLI executable should be named php-cli.exe. This seems like such a nobrainer. Am I missing something? Clue me in. It means I have to type four more characters, no thanks. (Just wanting to show that it's _your_ opinion to have it called php-cli.exe, which doesn't match my opinion). Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Mike Robinson wrote: Every system on the planet that uses php.exe as their CGI executable, and I suggest there are quite a few, will have a broken setup with a stock install of php-4.3.0, because typing php-cli.exe at the command line is too long. And you expect putting huge notes and warnings in the news file and installer will prevent this from happening. Any sysadmin upgrading to a new release should read the release notes, or be fired. (It's quite simple) There are a number of things to review before upgrading to PHP 4.3. One of the big things to note is that the CGI version of PHP has not been functioning correctly for some time now (see Shane's recent thread), and that 4.3 will finally correct this issue. The reason against renaming CGI and using its old name for the CLI now would have lead us to register_globals=ON for eternity. Totally different. Apples and oranges. That was a security-related change, and IMHO, the amount of trouble _that_ change caused far outweighed the meagre benefits achieved. It's called progress. We try to retain BC as much as possible and as much as makes sense, but sometimes we have to make some progress. That's what we are doing here. In case you haven't noticed, a lot of work is being done to elevate PHP beyond the status of a web-only language; this is a positive step in that direction. This change is going to break a lot of setups for the sake of cli users saving a few keystrokes. CGI was broken anyhow - this is going to *fix* a lot of setups, regardless of saving a few keystrokes. Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Shane Caraveo wrote: Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus Well, fortunately I never have time for qa, handling bugs, etc. etc. so I wont have to deal with the backlash that this name change **WILL** cause. I feel sorry for those who have the time to deal with it, as that will be about all they will deal with, rather than handling more important bugs and issues. Basicly, the namechange goes against several Don't worry, we'll make some quick-resolve for it too. We didn't get overwhelmed by that register_globals issue either. (like some people thought we would :) years of history in php, tons of documentation, general community knowledge, etc., and top it off with the fact that in reality, probably less than 1 percent of users use php as a command line language. It's evolution. :) And we do hope that the amount of people using PHP on command line increases. Besides, having the php-cgi binary makes it very clear what it is about. But naming the CLI binary php-cli definately does not. I'm actually a bit uncertain why we actually have separate binaries. (or I've forgot why they were separated..anyone?) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Jani Taskinen wrote: On Mon, 9 Dec 2002, Shane Caraveo wrote: Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus Well, fortunately I never have time for qa, handling bugs, etc. etc. so I wont have to deal with the backlash that this name change **WILL** cause. I feel sorry for those who have the time to deal with it, as that will be about all they will deal with, rather than handling more important bugs and issues. Basicly, the namechange goes against several Don't worry, we'll make some quick-resolve for it too. We didn't get overwhelmed by that register_globals issue either. (like some people thought we would :) years of history in php, tons of documentation, general community knowledge, etc., and top it off with the fact that in reality, probably less than 1 percent of users use php as a command line language. It's evolution. :) And we do hope that the amount of people using PHP on command line increases. Besides, having the php-cgi binary makes it very clear what it is about. But naming the CLI binary php-cli definately does not. I'm actually a bit uncertain why we actually have separate binaries. (or I've forgot why they were separated..anyone?) --Jani evolution doesn't cut it. It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. evolution would have been to fix the executable we have had, rather than creating multiple executables that do essentialy the same thing, and this issue would have been avoided altogether. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Mike Robinson wrote: Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. For whatever it's worth, I totally agree with you on this one, Mike. I just hope more people would come out and be vocal about this issue. Dear god, just imagine the amount of reports about their installations not working after upgrading to 4.3... Joao -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 14:52 09.12.2002, Mike Robinson wrote: Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson What do you want then? For historical reasons you will allow us only to introduce total new functionality and bug fixes? No more improvements that will have any influence on some working systems out there? Then i'll answer stay where you are and do not do any version upgrade evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 9 Dec 2002, Marcus Börger wrote: You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson What do you want then? For historical reasons you will allow us only to introduce total new functionality and bug fixes? No more improvements that will have any influence on some working systems out there? Then i'll answer stay where you are and do not do any version upgrade evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. You couldn't write my thoughts down in a better way :) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Shane Caraveo wrote: It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. Way back CGI and CLI *did* share one binary (the CGI binary) and the code was cluttered with code behaviour depending on the environment the binary was called in. The code with all these situation-dependant if() blocks was a true mess getting even worse with every new CGI- or CLI-only feature added. Even worse: some features and extensions don't make sense in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other features belong into a CGI binary only. The introduction of the seperate CLI binary or SAPI happened for two reasons: - removal of situation-dependant code in the CGI thus cleaning up the code base(as stated above) - the ability to build the CLI alongside with *every* SAPI So we can argue about binary naming, but definetly *not* about about the CGI/CLI split. No matter how similar the two binaries might look, they *aren't* -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 17:44 09.12.2002, Hartmut Holzgraefe wrote: Shane Caraveo wrote: It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. Way back CGI and CLI *did* share one binary (the CGI binary) and the code was cluttered with code behaviour depending on the environment the binary was called in. The code with all these situation-dependant if() blocks was a true mess getting even worse with every new CGI- or CLI-only feature added. Even worse: some features and extensions don't make sense in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other features belong into a CGI binary only. The introduction of the seperate CLI binary or SAPI happened for two reasons: - removal of situation-dependant code in the CGI thus cleaning up the code base(as stated above) - the ability to build the CLI alongside with *every* SAPI So we can argue about binary naming, but definetly *not* about about the CGI/CLI split. No matter how similar the two binaries might look, they *aren't* Thanks for the explanationi totally agree here with the exception being the name of the cli executable :-) marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 05:34 PM 12/9/2002 +0100, Marcus Börger wrote: At 14:52 09.12.2002, Mike Robinson wrote: Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson What do you want then? For historical reasons you will allow us only to introduce total new functionality and bug fixes? No more improvements that will have any influence on some working systems out there? Then i'll answer stay where you are and do not do any version upgrade evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking Why when I look at phpsh I think Sushi... John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
out on a limb Would it be a tragedy to name both the CLI and CGI versions php on UNIX and php.exe on Windows? On UNIX, it doesn't seem like there'd be much confusion because make install would put sapi/cli/php in /usr/local/bin and sapi/cgi/php in /usr/local/apache/cgi-bin. For the Windows distro, php.exe in the root of the archive could be the CGI (as usual) and sapi/php.exe could be the CLI version. It might be better to have sapi/cli/php.exe (along with parallel changes for the DLLs in that directory). /out on a limb Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. -Andrei http://www.gravitonic.com/ * Change is the only constant. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 19:46 09.12.2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. I am strongly against having two different names for the same thing on different machine targets. And Remeber: you can use the win executable by calling 'php' without '.exe' as well. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Hi, How big can this problem be ? There is basically only a few ways to install or upgrade PHP. 1) Installing from source or binaries, in this case you would have to know at least a minimum about how the system works and it is very easy to rename php-cgi.exe to php.exe on these these systems. 2) Using an installer. In this case the installer should make sure the correct file is used. This would be the way Win32 administrators are used to install/upgrade systems anyway. Some of the code I'm responsible for is used on more than 250 servers so I made sure my install program (which is a php script) makes the changes needed to match the version of PHP I use in each install/update.. - Frank On Mon, 9 Dec 2002, Marcus Börger wrote: You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson What do you want then? For historical reasons you will allow us only to introduce total new functionality and bug fixes? No more improvements that will have any influence on some working systems out there? Then i'll answer stay where you are and do not do any version upgrade evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. You couldn't write my thoughts down in a better way :) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Hi evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. marcus If you really want to easy shell access to php on windows you can provide a batch script for startup (php-cli %1). To save even more keystrokes, call this script p.bat and let it guess the file extension of the script itself(php-cli %1.php). Like this you would have to type p index instead of php index.php and you'd save 6 more keystrokes - even without a bc break. If you provide (a more advanced version of) this script with the win32 distribution as php.bat, everybody has what s(he) wants/needs. Or is this really a philosophical question? Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 20:35 09.12.2002, Christoph Grottolo wrote: Hi evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. marcus If you really want to easy shell access to php on windows you can provide a batch script for startup (php-cli %1). To save even more keystrokes, call this script p.bat and let it guess the file extension of the script itself(php-cli %1.php). Like this you would have to type p index instead of php index.php and you'd save 6 more keystrokes - even without a bc break. If you provide (a more advanced version of) this script with the win32 distribution as php.bat, everybody has what s(he) wants/needs. Or is this really a philosophical question? Christoph Seems so :-) If i want to use php on the command line i expect to call php. But then the problem seems to be the administrators :-( When installing a sapi for a web server i do it once and every time i update it i look if i have to change something in the setup - even file names. And before updating anything i test the stuff on a non production system. Therfore i do not see any administrator having a problem with renaming the cgi version. Only unexpirienced admins not following above rules will put themselves into trouble. But these can be helped and hopefully they learn that on next upgrade schedule they RTFM. People only experimenting without regard to manuals or with regard to outdated manuals are used to such problems. And then: why the hell do i write manual pages? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
When installing a sapi for a web server i do it once and every time i update it i look if i have to change something in the setup - even file names. And before updating anything i test the stuff on a non production system. I hope (and I know) there's more evolution in php 4.3 than a senseless rename of php.exe on windows. I know you're right - but beeing right is not always the same as doing the right thing. Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. These are good points. - Frank -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Andrei Zmievski [EMAIL PROTECTED] schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. reconfiguring iis to point to a new cgi is not a simple searchreplace as it is for other webservers, thus reconfiguring a site with many virtual webservers can be a horrible task. anyways the administrator is free to rename it back to php.exe, but in no case i would name both, the cli and the cgi, php.exe, that will cause lots of confusion imho. harald * Change is the only constant. * what will acceleration be in that context then ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. As I already said, we should put this in the message created at the end of ./configure, in the release notes, in the news file, on the website, and perhaps send a mass e-mail to everyone whom has ever worked with PHP ;) John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Thanks Hartmut, that added some much needed clarity. One comment I have to offer is the clutter you mention strongly suggests a refactoring was needed to lift from common code the CLI or CGI affected code. Including or omitting entire modules appropriate for each environment is also a pretty good argument for seperating the two variants. As Leon has suggested, why not just compile the variants into different directories? Say add a cli/ (since the CLI is newer). Only one directory would go into the PATH (presumably). In the case of the Win32 variant, it looks like distinct DLLs (if using a PHP DLL) might be a good idea. -Original Message- From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 8:44 AM Shane Caraveo wrote: It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. Way back CGI and CLI *did* share one binary (the CGI binary) and the code was cluttered with code behaviour depending on the environment the binary was called in. The code with all these situation-dependant if() blocks was a true mess getting even worse with every new CGI- or CLI-only feature added. Even worse: some features and extensions don't make sense in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other features belong into a CGI binary only. The introduction of the seperate CLI binary or SAPI happened for two reasons: - removal of situation-dependant code in the CGI thus cleaning up the code base(as stated above) - the ability to build the CLI alongside with *every* SAPI So we can argue about binary naming, but definetly *not* about about the CGI/CLI split. No matter how similar the two binaries might look, they *aren't* -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
As Leon has suggested, why not just compile the variants into different directories? Say add a cli/ (since the CLI is newer). Only one directory would go into the PATH (presumably). That would also affect the ini setting for extension_dir. The default value is ./ indicating the same directory as the executable. I would prefer everthing to be in the same directory. This way I dont have to mess with php.ini when I have multiple installations on the same system. - Frank -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
As Leon has suggested, why not just compile the variants into different directories? Say add a cli/ (since the CLI is newer). Only one directory would go into the PATH (presumably). That would also affect the ini setting for extension_dir. The default value is ./ indicating the same directory as the executable. I would prefer everthing to be in the same directory. This way I dont have to mess with php.ini when I have multiple installations on the same system. Yes, that's true. On the other hand, there's something strange about php.ini's extension_dir and the extensions directory. I found it a lot easier and cleaner to wipe out that line from php.ini than move all the extension up a directory. (If you don't set extension_dir, it uses c:\php4\extensions.) Wow, I guess I may have really stepped in it because I was just about to suggest the php.ini default setting change. ;) Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip On Sun, 8 Dec 2002, John Coggeshall wrote: I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip There was no spoon :-) ok start again: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcuis On Sun, 8 Dec 2002, John Coggeshall wrote: I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Admittedly I didn't hear whatever discussion went on before, but I wonder why the need for two different executables? It seems that the presence of the CGI variables SERVER_NAME and SERVER_SOFTWARE are pretty big hints, so you could decide at runtime whether to act as CGI or CLI. For completeness add a couple command line option to force CLI or CGI behavior and you're pretty much done. -Original Message- From: Marcus Borger [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 9:50 AM At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip There was no spoon :-) ok start again: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcuis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote: At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? There was no spoon :-) ok start again: Not sure what this means. There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Please provide version numbers so it can be documented. Like, WHEN the changes happened. Thanks, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Well no offence, but renaming the CGI executable is just plain wrong. The CLI executable should be named php-cli.exe. This seems like such a nobrainer. Am I missing something? Clue me in. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcus It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 19:28 08.12.2002, Philip Olson wrote: On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote: At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? There was no spoon :-) ok start again: From the film Matrix: ther is no spoon :-))) Not sure what this means. There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Please provide version numbers so it can be documented. Like, WHEN the changes happened. Thanks, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 20:37 08.12.2002, Christoph Grottolo wrote: Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcus It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). Christoph But in 4.2.x CLI sapi was experimental so there is no need to change anything because of that. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 22:08 08.12.2002, Mike Robinson wrote: Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson Just because you only need to type the name of the CGI sapi once: In other word one single time until we decide the name changes. But you will use a command line interface hopefully very often. I for one do and i am not going to type php-cli.exe because it is way much to long. The reason against renaming CGI and using its old name for the CLI now would have lead us to register_globals=ON for eternity. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Marcus Börger wrote: MBr Just because you only need to type the name of the CGI sapi once: MBr In other word one single time until we decide the name changes. MBr But you will use a command line interface hopefully very often. I MBr for one do and i am not going to type php-cli.exe because it is way MBr much to long. Sorry Marcus, but - even though I think these names are better - the same could be said for a cli: ln -s php-cli php or even: alias php /usr/local/bin/php-cli For windows - you could move php-cli.exe to C:\WINNT\system32\php.exe and it's preferred in the path (or set %PATH%). But - changing the name for the CGI, breaks server environments... I think on windows, the two executables, should be named the php.exe and the cgi stored in the standard php4 dir and the cli version in bin/. This way you have the best of both worlds - it won't break CGI - and a simple PATH adjustment takes care of the cli problem. For unices, we could provide a --with-cgi-name configure option and default to php, with --disable-cli. Just my 2c -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
As much as I understand the point of view that renaming the CGI version of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type 'php-cli' perhaps isn't such a good idea, I am completely against changing it now. Changing it the first time is obviously causing problems, changing it again will really muddle the waters... (Okay, if you downloaded PHP between the months of XXX and , it's this... Otherwise, it's that... Unless...) Regards, John -Original Message- From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 6:28 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] php.exe - php-cgi.exe On Sun, 8 Dec 2002, Marcus Börger wrote: MBr Just because you only need to type the name of the CGI sapi once: MBr In other word one single time until we decide the name changes. MBr But you will use a command line interface hopefully very often. I MBr for one do and i am not going to type php-cli.exe because it is MBr way much to long. Sorry Marcus, but - even though I think these names are better - the same could be said for a cli: ln -s php-cli php or even: alias php /usr/local/bin/php-cli For windows - you could move php-cli.exe to C:\WINNT\system32\php.exe and it's preferred in the path (or set %PATH%). But - changing the name for the CGI, breaks server environments... I think on windows, the two executables, should be named the php.exe and the cgi stored in the standard php4 dir and the cli version in bin/. This way you have the best of both worlds - it won't break CGI - and a simple PATH adjustment takes care of the cli problem. For unices, we could provide a --with-cgi-name configure option and default to php, with --disable-cli. Just my 2c -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: At 22:08 08.12.2002, Mike Robinson wrote: Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson Just because you only need to type the name of the CGI sapi once: In other word one single time until we decide the name changes. But you will use a command line interface hopefully very often. I for one do and i am not going to type php-cli.exe because it is way much to long. Every system on the planet that uses php.exe as their CGI executable, and I suggest there are quite a few, will have a broken setup with a stock install of php-4.3.0, because typing php-cli.exe at the command line is too long. And you expect putting huge notes and warnings in the news file and installer will prevent this from happening. The reason against renaming CGI and using its old name for the CLI now would have lead us to register_globals=ON for eternity. Totally different. Apples and oranges. That was a security-related change, and IMHO, the amount of trouble _that_ change caused far outweighed the meagre benefits achieved. This change is going to break a lot of setups for the sake of cli users saving a few keystrokes. Sorry. There's just no way this should happen. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, John Coggeshall wrote: JC JC As much as I understand the point of view that renaming the CGI version JC of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type JC 'php-cli' perhaps isn't such a good idea, I am completely against JC changing it now. Changing it the first time is obviously causing JC problems, changing it again will really muddle the waters... (Okay, if JC you downloaded PHP between the months of XXX and , it's this... JC Otherwise, it's that... Unless...) Ehm - the last __released__ version is php.exe vs. php-cli.exe. We shouldn't care about RC's/pre's and cvs builds. Live 'on the edge' - be prepared for a landing. JC JC Regards, JC JC John JC JC JC -Original Message- JC From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] JC Sent: Sunday, December 08, 2002 6:28 PM JC To: [EMAIL PROTECTED] JC Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] JC Subject: RE: [PHP-DEV] php.exe - php-cgi.exe JC JC JC On Sun, 8 Dec 2002, Marcus Börger wrote: JC JC MBr Just because you only need to type the name of the CGI JC sapi once: JC MBr In other word one single time until we decide the name changes. JC MBr But you will use a command line interface hopefully JC very often. I JC MBr for one do and i am not going to type php-cli.exe because it is JC MBr way much to long. JC JC Sorry Marcus, but - even though I think these names are better JC - the same could be said for a cli: ln -s php-cli php or even: JC alias php /usr/local/bin/php-cli JC JC For windows - you could move php-cli.exe to JC C:\WINNT\system32\php.exe and it's preferred in the path (or JC set %PATH%). JC JC But - changing the name for the CGI, breaks server environments... JC JC I think on windows, the two executables, should be named the JC php.exe and the cgi stored in the standard php4 dir and the JC cli version in bin/. This way you have the best of both worlds JC - it won't break CGI - and a simple PATH adjustment takes care JC of the cli problem. JC JC For unices, we could provide a --with-cgi-name configure JC option and default to php, with --disable-cli. JC JC Just my 2c JC -- JC With kind regards, JC JC Melvyn Sopacua JC ?php include(not_reflecting_employers_views.txt); ? JC JC JC -- JC PHP Development Mailing List http://www.php.net/ JC To unsubscribe, visit: http://www.php.net/unsub.php JC JC JC JC JC -- JC PHP Development Mailing List http://www.php.net/ JC To unsubscribe, visit: http://www.php.net/unsub.php JC JC -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 00:02 08.12.2002, Christoph Grottolo wrote: Hi In the NEWS file for 4.3.0 there should definitly be an entry about renaming php.exe to php-cgi.exe on win32, maybe this should even be mentioned on the download page together with the release. If not, there will be many bug reports about HTTP 500 errors and premature end of script headers after having installed PHP 4.3.0 as CGI on Win32. BTW, I still don't understand why php-cli cannot be called php-cli.exe on win32. Like this, many users would guess how the problem cgi and 4.3.0 can be solved even if they don't read php-dev (or the release notes). Christoph Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 00:35 08.12.2002, Christoph Grottolo wrote: Marcus Börger wrote: Christoph Grottolo wrote: BTW, I still don't understand why php-cli cannot be called php-cli.exe on win32. Like this, many users would guess how the problem cgi and 4.3.0 can be solved even if they don't read php-dev (or the release notes). Christoph Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus I understand the reason why cli has to get a short name (the lazyness of good programmers). What i don't understand is why it has to be called php.exe. You force each and every user of php-cgi on win32 to change his webserver configuration when switching to 4.3.0. yes but they will have to touch their ini files any way. Imagine if your favorite bar would rename wodka to gin because the barmen like wodka over gin and therefore want to give wodka a shorter name. For the next couple of months they will have to explain to every gin drinker that he now gets wodka when he orders gin and to every wodka drinker that he has to order gin when he wants wodka... know what i mean? I got your point (even though your example is slightly different as we do not exchange cgi and apache verwsion here). How many bug reports do you expect? 100? 500? Yes that could happen...maybe we should have another *big* message for the configure part and a *huge* message in the release notes and news entries. marcus Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Yes that could happen...maybe we should have another *big* message for the configure part and a *huge* message in the release notes and news entries. This is no different than when register_globals suddenly got turned off. I think a big ole' message at the end of ./configure will drastically reduce the number of problems. Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: I understand the reason why cli has to get a short name (the lazyness of good programmers). What i don't understand is why it has to be called php.exe. You force each and every user of php-cgi on win32 to change his webserver configuration when switching to 4.3.0. yes but they will have to touch their ini files any way. But not the webserver configuration. And: all the existing PHP HOWTOs will give them wrong information, some of them will never be updated... How many bug reports do you expect? 100? 500? Yes that could happen...maybe we should have another *big* message for the configure part and a *huge* message in the release notes and news entries. that's what i was asking for. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
