Re: [PHP-DEV] php-cgi vs php-cli naming issue
On Thu, 12 Dec 2002, Derick Rethans wrote: On Thu, 12 Dec 2002, Sterling Hughes wrote: How about we simply add a configure option to control this? --enable-simple-cli-name would build CGI as php-cgi and CLI as php That way we preserve BC and let those who like CLI named 'php' have that too. This will break the idea of having 'php' (the CLI) on as much systems as possible (for PEAR). It seems that integrating the two (CGI and CLI) _seems_ like the best solution, although I do not favor this due to technical reasons. For PEAR, it doesn't matter what the PHP binary name is, and since 1.0 will be co-released with PHP 4.3, PEAR will follow whatever PHP does. I agree with Zeev's stand on this. We (php-dev) are a bit too ego-centric if we think that it is reasonable to make lots of problems for existing CGI users just because we have some stubborn notion of what the CLI binary name should be. Ease up folks, and think about the users for a bit. IMHO some people are just a bit too eager breaking stuff around here. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-cgi vs php-cli naming issue
On Sun, 15 Dec 2002, Zeev Suraski wrote: At 15:48 15/12/2002, Derick Rethans wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). This is what we used to have. Maybe we can have a 'surefire' switch that ensures PHP starts up in CLI mode, so that invoking PHP from within a CGI won't cause it to run as a CGI itself? That sounds like it is needed. I only have one concern with integrating them, and that is how we are going to handle building the CLI/CGI and another sapi (like the apache module) at the same time. A lot of people do think this is quite useful. I dont see much problems though with this. Another point might be that not all extensions (like ncurses) are very useful in a CGI environment, but as I see that people using ncurses with PHP are pretty sparse, they can always recompile PHP if they really do not want the ncurses extension in their CGI. 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-cgi vs php-cli naming issue
I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? John 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-cgi vs php-cli naming issue
I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? Can you name a platform that this wouldn't work on? -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php-cgi vs php-cli naming issue
At 18:33 15.12.2002, John Coggeshall wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? John No, CGI is a well described standard. The only problem there is when someone experiments with the combined executable as a CGI with setting such vars and then forgets to remove the vars after testing is done. In this case he has changed the behaviour of his CLI executable. So i am against comining them back. Besides that i fear that we would have to restart release cycle... marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php-cgi vs php-cli naming issue
On Sun, 15 Dec 2002, Marcus Börger wrote: At 18:33 15.12.2002, John Coggeshall wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? No, CGI is a well described standard. The only problem there is when someone experiments with the combined executable as a CGI with setting such vars and then forgets to remove the vars after testing is done. In this case he has changed the behaviour of his CLI executable. By environment variables I meant thing that get set for the CGI itnerface. From http://hoohoo.ncsa.uiuc.edu/cgi/env.html you can read that the GATEWAY_INTERFACE is available for all requests, so it's safe to test if this one exists. So i am against comining them back. Besides that i fear that we would have to restart release cycle... The release cycle would be a problem indeed... 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-cgi vs php-cli naming issue
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 15, 2002 7:21 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'Stig S. Bakken'; 'Sterling Hughes'; 'Andrei Zmievski'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] php-cgi vs php-cli naming issue On Sun, 15 Dec 2002, Marcus Börger wrote: At 18:33 15.12.2002, John Coggeshall wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? No, CGI is a well described standard. The only problem there is when someone experiments with the combined executable as a CGI with setting such vars and then forgets to remove the vars after testing is done. In this case he has changed the behaviour of his CLI executable. By environment variables I meant thing that get set for the CGI itnerface. From http://hoohoo.ncsa.uiuc.edu/cgi/env.html you can read that the GATEWAY_INTERFACE is available for all requests, so it's safe to test if this one exists. So i am against comining them back. Besides that i fear that we would have to restart release cycle... The release cycle would be a problem indeed... Why do we need new releases every couple of weeks? Don't misunderstand me, I would really like to see 4.3 released, as this is the first version since around one year that will have only a few bugs on Tru64, on the other hand I'm really shocked, how buggy 4.3 will be on windows (http://lists.php.net/article.php?group=php.qaarticle=7279). I do not develop on windows, so I have no idea if PHP always was so buggy on windows, but in my eyes 4.3 is far from being ready to be released if you take the windows-versions. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php-cgi vs php-cli naming issue
On Sun, 15 Dec 2002, Sebastian Nohn wrote: Why do we need new releases every couple of weeks? Don't misunderstand me, I would really like to see 4.3 released, as this is the first version since around one year that will have only a few bugs on Tru64, on the other hand I'm really shocked, how buggy 4.3 will be on windows (http://lists.php.net/article.php?group=php.qaarticle=7279). I do not develop on windows, so I have no idea if PHP always was so buggy on windows, but in my eyes 4.3 is far from being ready to be released if you take the windows-versions. Did you actually read that report? If so, you would have noticed why most of the tests fail: just because the tests are flawed. 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-cgi vs php-cli naming issue
On Sun, 15 Dec 2002, John Coggeshall wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? The CGI interface uses environment variables, so if some platform doesn't have them, CGI doesn't work on it. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-cgi vs php-cli naming issue
How about we simply add a configure option to control this? --enable-simple-cli-name would build CGI as php-cgi and CLI as php That way we preserve BC and let those who like CLI named 'php' have that too. you mean instead of :: # mv php-cli php ? -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-cgi vs php-cli naming issue
On Thu, 12 Dec 2002, Sterling Hughes wrote: How about we simply add a configure option to control this? --enable-simple-cli-name would build CGI as php-cgi and CLI as php That way we preserve BC and let those who like CLI named 'php' have that too. This will break the idea of having 'php' (the CLI) on as much systems as possible (for PEAR). It seems that integrating the two (CGI and CLI) _seems_ like the best solution, although I do not favor this due to technical reasons. 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
