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
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
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
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
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
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
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
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
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
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
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
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
[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).
-
-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
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
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
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
]
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
[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
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 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:
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
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
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
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
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
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
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
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
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:
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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,
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
]]
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
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
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
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
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
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
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
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
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
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
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
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
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
]; '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
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
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
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
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
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
94 matches
Mail list logo
