Re: [PHP-DEV] CGI and CLI [packaging issues]
At 06:55 06.01.2003, Jean-Michel Dault wrote: Le sam 04/01/2003 à 18:13, Marcus Börger a écrit : What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... I'm CC'ing the maintainers of PHP for most distributions of Linux, so we can all be in sync. For those that don't know the issue, I'll resume it by saying that with PHP 4.3, there is a new CLI (command-line interface) that complements the CGI interface. The problem is, both files are named php. This will help a lot when coming from you. Here is the solution that I have been experimenting over the past few days, and that will be implemented in Mandrake Cooker (and soon 9.1): - There will be two RPMS: php-cli and php-cgi. - Both packages will provide php - Using the update-alternatives, each package will contain /usr/bin/php as a symlink to the respective binary. This lets us give a priority to which binary is called for a given symlink. php-cli will be given priority 20 (higher), php-cgi will be given priority 10 (lower) - If only one package is installed, /usr/bin/php will link to the right executable. - By default, php-cgi will be installed, in order to maintain backwards compatibility. - Users will be able to install the CLI using rpm -i php-cli - If both packages are installed, php-cli will be called since it's higher priority. - All packages that specifically require the command-line interface (there is none for the moment, but there will be in the future), will explicitely require php-cli. This setup means that we don't break the configuration of people that already have the php CGI interface, while, with one simple command, the new PHP command-line enthusiasts will be able to have their cake. This goes with the PHP source approach: By default, configure/make/make install compiles the CGI interface, and then you have to make install-cli to get the CLI. We just replace the make install-cli by urpmi/apt-get php-cli. Comments/Questions/Suggestions welcome. Jean-Michel Dault PHP/Apache packager Mandrake Linux From my point of view this is the best solution :-)) regards marcus aka helly -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 --
Re: [PHP-DEV] CGI and CLI [packaging issues]
This goes with the PHP source approach:
By default, configure/make/make install compiles the CGI interface,
and then you have to make install-cli to get the CLI.
We just replace the make install-cli by urpmi/apt-get php-cli.
Just FYI, 'make install-cli' is not the only way to
install the CLI there, 'make install' may put it
there too. For example:
'make install' copies CLI to {prefix}/bin/php
./configure --with-apxs
'make install' copies CGI to {prefix}/bin/php
./configure --enable-cli
'make install' copies CGI to {prefix}/bin/php
./configure
This is because both --enable-cgi and --enable-cli
are defaults. If one specifies a module SAPI, such
as apxs, then CLI is copied as 'php' because
--disable-cgi is implicitly called. This manual
entry explains this further:
http://www.php.net/features.commandline
This email is for informational purposes only, I do
not agree or disagree with your proposal as I wouldn't
touch this with a large stick but just wanted to clear
up any possible misconceptions :)
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI [packaging issues]
Le sam 04/01/2003 à 18:13, Marcus Börger a écrit : What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... I'm CC'ing the maintainers of PHP for most distributions of Linux, so we can all be in sync. For those that don't know the issue, I'll resume it by saying that with PHP 4.3, there is a new CLI (command-line interface) that complements the CGI interface. The problem is, both files are named php. Here is the solution that I have been experimenting over the past few days, and that will be implemented in Mandrake Cooker (and soon 9.1): - There will be two RPMS: php-cli and php-cgi. - Both packages will provide php - Using the update-alternatives, each package will contain /usr/bin/php as a symlink to the respective binary. This lets us give a priority to which binary is called for a given symlink. php-cli will be given priority 20 (higher), php-cgi will be given priority 10 (lower) - If only one package is installed, /usr/bin/php will link to the right executable. - By default, php-cgi will be installed, in order to maintain backwards compatibility. - Users will be able to install the CLI using rpm -i php-cli - If both packages are installed, php-cli will be called since it's higher priority. - All packages that specifically require the command-line interface (there is none for the moment, but there will be in the future), will explicitely require php-cli. This setup means that we don't break the configuration of people that already have the php CGI interface, while, with one simple command, the new PHP command-line enthusiasts will be able to have their cake. This goes with the PHP source approach: By default, configure/make/make install compiles the CGI interface, and then you have to make install-cli to get the CLI. We just replace the make install-cli by urpmi/apt-get php-cli. Comments/Questions/Suggestions welcome. Jean-Michel Dault PHP/Apache packager Mandrake Linux -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 22:41 03.01.2003, Jean-Michel Dault wrote: Hello all, Sorry to re-activate this topic, but I stumbled into an issue when packaging PHP 4.3 as an RPM for Mandrake. What happens when a user wants to install *both* php-cli and php-cgi? You cannot have two files with the same name, either in the same RPM, or in two different RPMS... This is not RPM specific, since it will create the same problem with apt, pkgtool, or others. But why would he want to? AFAIK Mandrake uses php as an apache module and CLI can be used on the commandline. If the user still wants to have CGI by a RPM then i would go for naming it to whatever name you like different from that of the executable in the CLI RPM. Since RPM can handle all installation problems everything is fine then. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Le sam 04/01/2003 à 08:15, Marcus Börger a écrit : What happens when a user wants to install *both* php-cli and php-cgi? You cannot have two files with the same name, either in the same RPM, or in two different RPMS... This is not RPM specific, since it will create the same problem with apt, pkgtool, or others. But why would he want to? AFAIK Mandrake uses php as an apache module and CLI can be used on the commandline. If the user still wants to have CGI by a RPM then i would go for naming it to whatever name you like different from that of the executable in the CLI RPM. Since RPM can handle all installation problems everything is fine then. Concrete example from our demanding users: If someone wants to have Apache running PHP, but provide secure PHP in a chrooted environment for users home directories, they use cgiwrap, thus php-cgi. But if they use PEAR and php-gtk as well, they'll need the php-cli. What you're suggesting is that, when both cgi and cli are installed, the cli version is called php, and the php-cgi is called something else. This creates these problems: - If someone used the cgi version before, it will no longer work, since the php-cli doesn't write the headers - If someone used the cgi version in command-line mode, and install the new cli version, some scripts will be broken, because of the way it does not change directories before executing the script. So the default behavior is to have php-cgi, and have some additional steps to have the CLI. In the source edition, you have to do make install-cli, in Mandrake, you'll have to do rpm -i php-cli. So what I'll do is the following: - The standard php binary will be the CGI version, will be called php-cgi, and have a priority of 20. - There will be an additional php-cli package, and will have a priority of 10. - I will use the update-alternatives method to provide a symbolic link to /usr/bin/php. If only one package is installed, calling PHP will call the right one. If both are installed, calling php will translate to php-cgi, which has the highest priority. Users who have both packages will still be able to chose if they give the proper binary name. Does this make sense to you? Jean-Michel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 21:57 04.01.2003, Jean-Michel Dault wrote: Le sam 04/01/2003 à 08:15, Marcus Börger a écrit : What happens when a user wants to install *both* php-cli and php-cgi? You cannot have two files with the same name, either in the same RPM, or in two different RPMS... This is not RPM specific, since it will create the same problem with apt, pkgtool, or others. But why would he want to? AFAIK Mandrake uses php as an apache module and CLI can be used on the commandline. If the user still wants to have CGI by a RPM then i would go for naming it to whatever name you like different from that of the executable in the CLI RPM. Since RPM can handle all installation problems everything is fine then. Concrete example from our demanding users: If someone wants to have Apache running PHP, but provide secure PHP in a chrooted environment for users home directories, they use cgiwrap, thus php-cgi. But if they use PEAR and php-gtk as well, they'll need the php-cli. Ok, good point. What you're suggesting is that, when both cgi and cli are installed, the cli version is called php, and the php-cgi is called something else. This creates these problems: - If someone used the cgi version before, it will no longer work, since the php-cli doesn't write the headers - If someone used the cgi version in command-line mode, and install the new cli version, some scripts will be broken, because of the way it does not change directories before executing the script. So the default behavior is to have php-cgi, and have some additional steps to have the CLI. In the source edition, you have to do make install-cli, in Mandrake, you'll have to do rpm -i php-cli. So what I'll do is the following: - The standard php binary will be the CGI version, will be called php-cgi, and have a priority of 20. - There will be an additional php-cli package, and will have a priority of 10. - I will use the update-alternatives method to provide a symbolic link to /usr/bin/php. If only one package is installed, calling PHP will call the right one. If both are installed, calling php will translate to php-cgi, which has the highest priority. Users who have both packages will still be able to chose if they give the proper binary name. Does this make sense to you? Since i favor CLI being called php i would prefer that solution. And IMO security through cgi and suexec and such is only a hack (even though a good one at current time). However i see the main problem and can live with both solutions because i will not install CGI where i need CLI and on those systems where i need CGI i can live without CLI for now. What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... That's a minor problem for me, since the shebang is never standard. Some people put it in /usr/local, some in /opt, some in /usr/bin, so anyways you have to modify it. And with my approach, php will still be called php, with the symbolic links. Jean-Michel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Hello all, Sorry to re-activate this topic, but I stumbled into an issue when packaging PHP 4.3 as an RPM for Mandrake. What happens when a user wants to install *both* php-cli and php-cgi? You cannot have two files with the same name, either in the same RPM, or in two different RPMS... This is not RPM specific, since it will create the same problem with apt, pkgtool, or others. For Windows, the php.exe and cli/php.exe is good, but on Unix, it would be bad to have, say, /usr/bin/php and /usr/bin/cli/php! Here is yet another compromise (for Unix) 1) - name the cli version php-cli 2) - name the cgi version php-cgi 3) - use a wrapper script, symbolic link or another tool (such as update-alternatives for Linux), to decide which one to call. 4) - tell everyone to change their scripts for the future, so it points to the right php version. Step #4 is not that bad, since we always have to change the 1st line of the scripts anyways... You never know where php is installed, since DESTDIR is a variable. And with the wrapper script, we keep BC, at the expense of a slowdown of performance. What do you think? PS: please answer to me personnaly, as I don't check this mailing list often. Regards, Jean-Michel Dault Apache/PHP maintainer, Mandrake Linux Le jeu 19/12/2002 à 10:33, Edin Kadribasic a écrit : After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. 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] CGI and CLI (compromise proposal)
On Fri, 20 Dec 2002, Marcus Börger wrote: What about uniqid(): http://www.zend.com/zend/week/week116.php#Heading5 I would go for disabling when not available and sending an error when calling from cygwin without more entropy parameter set to true. The rest can be fixed for 4.3.1 as it seems to late for a fix in 4.3.0. Fine with me. -Andrei http://www.gravitonic.com/ The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners. - Ernst Jan Plugge -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
At 23:21 18.12.2002, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Philip Olson wrote: So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. The merging of CLI and CGI will still happen, but in 4.3.1. That would be a very bad thing. If we want this we should do it for 4.3.0 instead of having different installations every now and then. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
At 20:59 18.12.2002, Andrei Zmievski wrote:
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a consensus at all? I full plan to go ahead with 4.3.0 release
before the end of the year, so those interested in doing anything about
this issue better get their butts in gear.
-Andrei
After reading through the whole thread i came to the conclusion that there
are two
parties. The first wants BC for all costs and the second wants
improovements. The
improovement party started the whole issue.
They wanted to overcome the necessary workarounds that allows CGI being
used as
a shell utility (mostly with shebang lines like with perl). To accomplish
this the best
way seemed to have a new executable handling this correctly (and different
than CGI).
This required the new executable CLI being called php to have it beeing a
replacement.
At this point it that was not considered being a problem for two reasons.
First CGI has
to be installed anyway and second noone thought about windows problems at that
time. So far the history as i see/remeber it.
Then the problem on windows was reported and the BC party got alarmed
claimed that
new things have to have new names and all BC has to be kept. (point)
From my point of view having CLI with a different name than php does not
make much
sense but it is far more better than merging the two. Merging would make
the code
allmost unreadable and would also slow down the code (where are those
saying speed
is everything?). And of cause merging is against the idea that we will have
different
behaviour from different executables for different tasks. (And edin already
showed an
example where merging will leed to errors).
And now to the ideas mentioned from several people here:
a) Merging CLI CGI read above.
b) Merging in 4.3.1 seems the worst thing we can do. It contradicts nearly
all thoughts
we have heared here just to have 4.3.0 out asap. But more important it
leeds to one
more different behaving version. And most important it contradicts one
rule: Only bug
fixes in such releases.
c) --install-cli[=dir] + --install-cgi[=dir]: Nice idea but we do not have
a real problem under
*nix. The problem is in windows. However i like the idea but think that
having defaults
for them is necessary (For me that would be --install-cli={$prefix]/bin and
CGI to something
differnet).
d) keeping CGI and CLI in their sapi directories before installation is a
good idea. It would
make handling easier and clearer. If there is no php in ./ i know what php
i get when
fetching it from a sapi directory.
e) having both using the name php will confuse the users way to much. And
we would
reach the opposite of what started the issue: less bugreports and questions.
f) Throwing an error or notice when missusing one of the two seems a good
idea to me
as long as this message can be disabled (See example shown by edin). And i
do not see
any problem with that. In fact that would be the best solution to introduce
such changes
because notes and hints in documents or readmes are being ignored by to
many users.
g) Calling CGI from CLI when CLI is used as CGI seems a good idea as long
as it can be
disabled at first sight. But it makes things more complicated and e) is the
better way.
h) None of the above solves the problem under windows: But i do not get it:
Even on
windows an executable can be called with its full path. So there is only a
little change
that has do be done on all platforms when renaming CGI executable to
php-cgi: Only
one configure line has to be changed. And those users being to lazy to read
installation
docs, news and change logs can be given hints by e).
i) We are late in release process.
After all this points we have to question ourselves: Do we want php
becoming a widely
accepted command line utility (which it is already for many users) even
when this will
cost use to mark some bug reports bogus or documentation problems? Isn't it
a fact
that sometimes evolution requires changes?
Just to make my conclusion clear: I favor CGI with the new name php-cgi +
c) d) e)
since BC is not everything.
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
I think you forgot to take one fact into account - PHP 4.2.x already had
CLI/CGI binaries, both having the same name. Keeping 4.3 with the 4.2
behavior, and then merging the modules back in 4.3.1 is the best solution
as far as I can tell. Merging the modules does not have serious
compatibility-breaking drawbacks, and either way, these drawbacks, if any,
will be identical whether they happen in 4.3 or 4.3.1.
About 'BC at all costs', I'm a big advocate of BC, but describing this
issue as 'BC at all costs' is just plain wrong. The cost here is tiny,
it's a tiny price to pay for BC and simplicity.
Zeev
At 14:14 19/12/2002, Marcus Börger wrote:
At 20:59 18.12.2002, Andrei Zmievski wrote:
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a consensus at all? I full plan to go ahead with 4.3.0 release
before the end of the year, so those interested in doing anything about
this issue better get their butts in gear.
-Andrei
After reading through the whole thread i came to the conclusion that there
are two
parties. The first wants BC for all costs and the second wants
improovements. The
improovement party started the whole issue.
They wanted to overcome the necessary workarounds that allows CGI being
used as
a shell utility (mostly with shebang lines like with perl). To accomplish
this the best
way seemed to have a new executable handling this correctly (and different
than CGI).
This required the new executable CLI being called php to have it beeing a
replacement.
At this point it that was not considered being a problem for two reasons.
First CGI has
to be installed anyway and second noone thought about windows problems at that
time. So far the history as i see/remeber it.
Then the problem on windows was reported and the BC party got alarmed
claimed that
new things have to have new names and all BC has to be kept. (point)
From my point of view having CLI with a different name than php does not
make much
sense but it is far more better than merging the two. Merging would make
the code
allmost unreadable and would also slow down the code (where are those
saying speed
is everything?). And of cause merging is against the idea that we will
have different
behaviour from different executables for different tasks. (And edin
already showed an
example where merging will leed to errors).
And now to the ideas mentioned from several people here:
a) Merging CLI CGI read above.
b) Merging in 4.3.1 seems the worst thing we can do. It contradicts nearly
all thoughts
we have heared here just to have 4.3.0 out asap. But more important it
leeds to one
more different behaving version. And most important it contradicts one
rule: Only bug
fixes in such releases.
c) --install-cli[=dir] + --install-cgi[=dir]: Nice idea but we do not have
a real problem under
*nix. The problem is in windows. However i like the idea but think that
having defaults
for them is necessary (For me that would be --install-cli={$prefix]/bin
and CGI to something
differnet).
d) keeping CGI and CLI in their sapi directories before installation is a
good idea. It would
make handling easier and clearer. If there is no php in ./ i know what php
i get when
fetching it from a sapi directory.
e) having both using the name php will confuse the users way to much. And
we would
reach the opposite of what started the issue: less bugreports and questions.
f) Throwing an error or notice when missusing one of the two seems a good
idea to me
as long as this message can be disabled (See example shown by edin). And i
do not see
any problem with that. In fact that would be the best solution to
introduce such changes
because notes and hints in documents or readmes are being ignored by to
many users.
g) Calling CGI from CLI when CLI is used as CGI seems a good idea as long
as it can be
disabled at first sight. But it makes things more complicated and e) is
the better way.
h) None of the above solves the problem under windows: But i do not get
it: Even on
windows an executable can be called with its full path. So there is only a
little change
that has do be done on all platforms when renaming CGI executable to
php-cgi: Only
one configure line has to be changed. And those users being to lazy to
read installation
docs, news and change logs can be given hints by e).
i) We are late in release process.
After all this points we have to question ourselves: Do we want php
becoming a widely
accepted command line utility (which it is already for many users) even
when this will
cost use to mark some bug reports bogus or documentation problems? Isn't
it a fact
that sometimes evolution requires changes?
Just to make my conclusion clear: I favor CGI with the new name php-cgi +
c) d) e)
since BC is not everything.
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:
Re: [PHP-DEV] CGI and CLI
At 13:23 19.12.2002, Zeev Suraski wrote:
I think you forgot to take one fact into account - PHP 4.2.x already had
CLI/CGI binaries, both having the same name. Keeping 4.3 with the 4.2
behavior, and then merging the modules back in 4.3.1 is the best solution
as far as I can tell. Merging the modules does not have serious
compatibility-breaking drawbacks, and either way, these drawbacks, if any,
will be identical whether they happen in 4.3 or 4.3.1.
As i said: If merging then merging in 4.3.0. I do not see any reason not to
make
such changes in 4.3.0 besides the time of 4.3.0 release.
About 'BC at all costs', I'm a big advocate of BC, but describing this
issue as 'BC at all costs' is just plain wrong. The cost here is tiny,
it's a tiny price to pay for BC and simplicity.
Zeev
I used the phrase BC at all costs to over emphasize the following: Having
any name
other than php is really bad for CLI.
You are right to say the cost is tiny if the solution is merging. But i am
for instance
strongly against that.
I forgot to recall one more thing: CLI is EXPERIMENTAL in 4.2.x so keeping
CLI as
in 4.2.x is the least important thing in this whole issue.
At 14:14 19/12/2002, Marcus Börger wrote:
At 20:59 18.12.2002, Andrei Zmievski wrote:
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a consensus at all? I full plan to go ahead with 4.3.0 release
before the end of the year, so those interested in doing anything about
this issue better get their butts in gear.
-Andrei
After reading through the whole thread i came to the conclusion that
there are two
parties. The first wants BC for all costs and the second wants
improovements. The
improovement party started the whole issue.
They wanted to overcome the necessary workarounds that allows CGI being
used as
a shell utility (mostly with shebang lines like with perl). To accomplish
this the best
way seemed to have a new executable handling this correctly (and
different than CGI).
This required the new executable CLI being called php to have it beeing a
replacement.
At this point it that was not considered being a problem for two reasons.
First CGI has
to be installed anyway and second noone thought about windows problems at
that
time. So far the history as i see/remeber it.
Then the problem on windows was reported and the BC party got alarmed
claimed that
new things have to have new names and all BC has to be kept. (point)
From my point of view having CLI with a different name than php does not
make much
sense but it is far more better than merging the two. Merging would make
the code
allmost unreadable and would also slow down the code (where are those
saying speed
is everything?). And of cause merging is against the idea that we will
have different
behaviour from different executables for different tasks. (And edin
already showed an
example where merging will leed to errors).
And now to the ideas mentioned from several people here:
a) Merging CLI CGI read above.
b) Merging in 4.3.1 seems the worst thing we can do. It contradicts
nearly all thoughts
we have heared here just to have 4.3.0 out asap. But more important it
leeds to one
more different behaving version. And most important it contradicts one
rule: Only bug
fixes in such releases.
c) --install-cli[=dir] + --install-cgi[=dir]: Nice idea but we do not
have a real problem under
*nix. The problem is in windows. However i like the idea but think that
having defaults
for them is necessary (For me that would be --install-cli={$prefix]/bin
and CGI to something
differnet).
d) keeping CGI and CLI in their sapi directories before installation is a
good idea. It would
make handling easier and clearer. If there is no php in ./ i know what
php i get when
fetching it from a sapi directory.
e) having both using the name php will confuse the users way to much. And
we would
reach the opposite of what started the issue: less bugreports and questions.
f) Throwing an error or notice when missusing one of the two seems a good
idea to me
as long as this message can be disabled (See example shown by edin). And
i do not see
any problem with that. In fact that would be the best solution to
introduce such changes
because notes and hints in documents or readmes are being ignored by to
many users.
g) Calling CGI from CLI when CLI is used as CGI seems a good idea as long
as it can be
disabled at first sight. But it makes things more complicated and e) is
the better way.
h) None of the above solves the problem under windows: But i do not get
it: Even on
windows an executable can be called with its full path. So there is only
a little change
that has do be done on all platforms when renaming CGI executable to
php-cgi: Only
one configure line has to be changed. And those users being to lazy to
read installation
docs, news and change logs can be given hints by e).
i) We are late in release process.
After all this points we have to question
RE: [PHP-DEV] CGI and CLI (compromise proposal)
-Original Message- From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 3:34 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] CGI and CLI (compromise proposal) After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. I think this is the best idea so far as it can be implemented (and released ;) fast, would not break BC and gives people who want to use the cli-version to use php. 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] CGI and CLI (compromise proposal)
If my vote has enough Karma Power, then I'm +1 for this solution. --Wez. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 15:33 19.12.2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. Edin I am +1 with respect to latest -+ [01] discussion marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Here is the patch against PHP_4_3 that implements the Unix side of changes. Edin On Thu, 19 Dec 2002, Andrei Zmievski wrote: This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * Index: configure.in === RCS file: /repository/php4/configure.in,v retrieving revision 1.396.2.15 diff -u -3 -p -r1.396.2.15 configure.in --- configure.in13 Dec 2002 13:34:37 - 1.396.2.15 +++ configure.in19 Dec 2002 16:45:38 - @@ -1081,7 +1081,11 @@ INLINE_CFLAGS=$INLINE_CFLAGS $standard_ CXXFLAGS=$CXXFLAGS $standard_libtool_flag all_targets='$(OVERALL_TARGET) $(PHP_MODULES) $(PHP_CLI_TARGET)' -install_targets=install-sapi install-modules $PHP_INSTALL_CLI_TARGET $install_pear +install_targets=install-sapi install-modules $install_pear +if test $PHP_SAPI != cgi; then + install_targets=$PHP_INSTALL_CLI_TARGET $install_targets +fi + PHP_SUBST(all_targets) PHP_SUBST(install_targets) Index: sapi/cgi/config9.m4 === RCS file: /repository/php4/sapi/cgi/config9.m4,v retrieving revision 1.1.2.2 diff -u -3 -p -r1.1.2.2 config9.m4 --- sapi/cgi/config9.m4 9 Dec 2002 17:25:01 - 1.1.2.2 +++ sapi/cgi/config9.m4 19 Dec 2002 16:45:38 - @@ -88,10 +88,10 @@ if test $PHP_SAPI = default; then PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/sapi/cgi/Makefile.frag) case $host_alias in *cygwin* ) -SAPI_CGI_PATH=sapi/cgi/php-cgi.exe +SAPI_CGI_PATH=sapi/cgi/php.exe ;; * ) -SAPI_CGI_PATH=sapi/cgi/php-cgi +SAPI_CGI_PATH=sapi/cgi/php ;; esac PHP_SUBST(SAPI_CGI_PATH) @@ -147,7 +147,7 @@ if test $PHP_SAPI = default; then AC_DEFINE_UNQUOTED(PHP_FCGI_STATIC, $PHP_FCGI_STATIC, [ ]) AC_MSG_RESULT($PHP_ENABLE_FASTCGI) -INSTALL_IT=\$(INSTALL) -m 0755 \$(SAPI_CGI_PATH) \$(INSTALL_ROOT)\$(bindir)/php-cgi +INSTALL_IT=\$(INSTALL) -m 0755 \$(SAPI_CGI_PATH) \$(INSTALL_ROOT)\$(bindir)/php PHP_SELECT_SAPI(cgi, program, $PHP_FCGI_FILES cgi_main.c getopt.c, -I$PHP_FCGI_INCLUDE,'$(SAPI_CGI_PATH)') case $host_alias in -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Edin Kadribasic wrote: If this is an acceptable compromise I volunteer to do the changes required. Sounds reasonable to me, +1. -- 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] CGI and CLI (compromise proposal)
On Thu, 19 Dec 2002, Edin Kadribasic wrote: Here is the patch against PHP_4_3 that implements the Unix side of changes. Go ahead and apply it. We obviously need RC4 now so commit your critical fixes to other areas ASAP, because I want to release the RC tonight or tomorrow. -Andrei http://www.gravitonic.com/ * Unix is user friendly, it is just chooses its users selectively. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
I'm 95% that PEAR works with cgi, but we should check with Stig to make sure it doesn't assume that cli will always be installed. Since pear and cli were both going live with 4.3 they may be coupled. -adam On Thu, 19 Dec 2002, Andrei Zmievski wrote: This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Edin, Are you doing the changes on Win32 also _ If not I'll make the changes. - Frank Here is the patch against PHP_4_3 that implements the Unix side of changes. Edin On Thu, 19 Dec 2002, Andrei Zmievski wrote: This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
Just testing the patch... will be commiting shortly. Thanks anyway, Edin - Original Message - From: Frank M. Kromann [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Andrei Zmievski [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 6:44 PM Subject: Re: [PHP-DEV] CGI and CLI (compromise proposal) Edin, Are you doing the changes on Win32 also _ If not I'll make the changes. - Frank Here is the patch against PHP_4_3 that implements the Unix side of changes. Edin On Thu, 19 Dec 2002, Andrei Zmievski wrote: This gets my complete support. Let's go ahead with the changes. On Thu, 19 Dec 2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. -Andrei http://www.gravitonic.com/ * The great thing about standards is that there are so many to choose from. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. This goes to show that good ideas usually win out and our system works. I proposed cli/php.exe on Windows back on December 9th, but there was a fear it would be a support nightmare. I take it those fears have subsided. I'm also glad that limb I went out on didn't break afterall. I'd say that I fully support this proposal but I'm not sure my opinion matters. ;) Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 17:53 19.12.2002, Andrei Zmievski wrote: On Thu, 19 Dec 2002, Edin Kadribasic wrote: Here is the patch against PHP_4_3 that implements the Unix side of changes. Go ahead and apply it. We obviously need RC4 now so commit your critical fixes to other areas ASAP, because I want to release the RC tonight or tomorrow. -Andrei http://www.gravitonic.com/ * Unix is user friendly, it is just chooses its users selectively. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php What about uniqid(): http://www.zend.com/zend/week/week116.php#Heading5 I would go for disabling when not available and sending an error when calling from cygwin without more entropy parameter set to true. The rest can be fixed for 4.3.1 as it seems to late for a fix in 4.3.0. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote On Wed, 2002-12-18 at 14:59, Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei http://www.gravitonic.com/ This isn't right. This isn't even wrong. -- Wolfgang Pauli -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? -Sterling On Wed, 2002-12-18 at 14:59, Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei http://www.gravitonic.com/ This isn't right. This isn't even wrong. -- Wolfgang Pauli -- Xavier Spriet [EMAIL PROTECTED] -- 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] CGI and CLI
The problems that can occur that I can think of are: - Crontabs calling the php CLI binary - CLI scripts starting with #!/usr/bin/php - Scripts from other languages calling for a specific binary - and also all the users that call the CLI binary directly by its name. I agree that the old binary will still remain there but then none of these scenarios can actually benefit of a new release if it actually fixes a bug preventing it from working properly. On Wed, 2002-12-18 at 15:30, Sterling Hughes wrote: This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? -Sterling On Wed, 2002-12-18 at 14:59, Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei http://www.gravitonic.com/ This isn't right. This isn't even wrong. -- Wolfgang Pauli -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. MfG, Sebastian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? 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] CGI and CLI
Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. MfG, Sebastian -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. -Andrei http://www.gravitonic.com/ The 3 great virtues of a programmer: Laziness, Impatience, and Hubris. --Larry Wall -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) [derick@saturnus php-4.2.1]$ ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 11 13:24 sapi/cli/php 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] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:50 PM To: Sebastian Nohn Cc: PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. The best solution would be indeed bundling both to one binary. If this delays a 4.3.0-release? I don't give a damn about it! The idea release fast, release often is completely ridiculous in my eyes. If you would like to release 4.3.0 as soon as possible simply let php be php (i talk about the cgi-version), mark cgi still as experimental and work on the integration to one binary for 4.3.1 or 5.0.0. 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] CGI and CLI
If it gets done that way it will be really confusing for everyone... All users used to CLI as php will need to switch to php-cli for 4.3.0 then back to php afterwards ? I think if there's not enough time to merge both back together, it would be wiser to wait a bit, at least until it's done if it isn't already done. On Wed, 2002-12-18 at 16:03, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Andi -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. The best solution would be indeed bundling both to one binary. If this delays a 4.3.0-release? I don't give a damn about it! The idea release fast, release often is completely ridiculous in my eyes. If you would like to release 4.3.0 as soon as possible simply let php be php (i talk about the cgi-version), mark cgi still as experimental and work on the integration to one binary for 4.3.1 or 5.0.0. This is not even the issue here since both would be merged together in one binary that would be able to figure out in which context it was called.. I agree for the delay... Quality Quantity 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/ -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote: On Wed, 18 Dec 2002, Sebastian Nohn wrote: This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. 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] CGI and CLI
Again: Thousands if not millions of servers use PHP as CGI. Who uses PHP for CLI-apps? 100? 1000? 5000? If you use experimental technology you always MUST have in mind that anything can change anytime. Why was'nt PHP available for Apache 2 for a long time (is it in the meantime btw.?)?. Because Apache Group continiously changed their API. -Original Message- From: Xavier Spriet [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:53 PM To: Sebastian Nohn Cc: Sterling Hughes; Andrei Zmievski; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. MfG, Sebastian -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:03 PM To: Andrei Zmievski; Xavier Spriet Cc: Sebastian Nohn; Sterling Hughes; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) +1 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] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:05 PM To: Andi Gutmans Cc: PHP Developers Subject: Re: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) [derick@saturnus php-4.2.1]$ ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 11 13:24 sapi/cli/php That's not the issue. The point is that cgi-version will be renamed to php-cgi, breaking a lot of installations = hundreds of new bogus bugs. Again: nobody reads release-notes. 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] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote: -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:05 PM To: Andi Gutmans Cc: PHP Developers Subject: Re: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) [derick@saturnus php-4.2.1]$ ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 11 13:24 sapi/cli/php That's not the issue. The point is that cgi-version will be renamed to php-cgi, breaking a lot of installations = hundreds of new bogus bugs. Hello there? I didn't not say that we should rename the php CGI to php-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] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:14 PM To: Sebastian Nohn Cc: PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Sebastian Nohn wrote: On Wed, 18 Dec 2002, Sebastian Nohn wrote: This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. But renaming php-cli to php means renaming php to anything else (php-cgi, cgi-php, phpcgi, phpfoo, whatever), right? 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] CGI and CLI
On Wed, 2002-12-18 at 16:17, Sebastian Nohn wrote: Again: Thousands if not millions of servers use PHP as CGI. PHP-CGI will _NOT_ be renamed either. Who uses PHP for CLI-apps? 100? 1000? 5000? If you use experimental technology you always MUST have in mind that anything can change anytime. Why was'nt PHP available for Apache 2 for a long time (is it in the meantime btw.?)?. Because Apache Group continiously changed their API. -Original Message- From: Xavier Spriet [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:53 PM To: Sebastian Nohn Cc: Sterling Hughes; Andrei Zmievski; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. MfG, Sebastian -- Xavier Spriet [EMAIL PROTECTED] -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:20 PM To: Sebastian Nohn Cc: Andi Gutmans; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Sebastian Nohn wrote: -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:05 PM To: Andi Gutmans Cc: PHP Developers Subject: Re: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) [derick@saturnus php-4.2.1]$ ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 11 13:24 sapi/cli/php That's not the issue. The point is that cgi-version will be renamed to php-cgi, breaking a lot of installations = hundreds of new bogus bugs. Hello there? I didn't not say that we should rename the php CGI to php-cgi. But you said a php-cli would piss of some users: -- cut here --- Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? -- cut here --- 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] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote: But renaming php-cli to php means renaming php to anything else (php-cgi, cgi-php, phpcgi, phpfoo, whatever), right? No, we didn't do that for 4.2.[0-3] either: [root@saturnus php-4.2.1]# ./configure --enable-cli [root@saturnus php-4.2.1]# make CGI: [root@saturnus php-4.2.1]# ls -l ./php -rwxr-xr-x1 root root 2915010 Dec 18 22:24 ./php CLI: [root@saturnus php-4.2.1]# ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 18 22:24 sapi/cli/php 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] CGI and CLI
On Wed, 18 Dec 2002, Derick Rethans wrote: [...] I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. Derick Why don't you just add a simple check in the CLI code to exec() the CGI binary if it is called as a CGI? if(getenv(GATEWAY_INTERFACE) != NULL) execv(/path/to/php-cgi, argv); or something. Call it a transition path until people get used to using php-cgi. I've been reading arguments on this very topic for weeks now. I would hate to see this delay the release of 4.3 any further. Respectfully, /Robin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Xavier Spriet [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:25 PM To: Sebastian Nohn Cc: Sterling Hughes; Andrei Zmievski; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 2002-12-18 at 16:17, Sebastian Nohn wrote: Again: Thousands if not millions of servers use PHP as CGI. PHP-CGI will _NOT_ be renamed either. For clearness: The cgi-version of php will be called php-cgi? If this stands firm, why this discussion? 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] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote: I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. The best solution would be indeed bundling both to one binary. If this delays a 4.3.0-release? I don't give a damn about it! The idea release fast, release often is completely ridiculous in my eyes. Release early, release often?? Have you bothered to check when 4.2.0 came out? Let me refresh your memory: 22 Apr 2002. That's 8 months ago. For a point release. That is what's ridiculous. -Andrei http://www.gravitonic.com/ * On the keyboard of life, always keep one finger on the escape key. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Sebastian Nohn wrote: I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. The best solution would be indeed bundling both to one binary. If this delays a 4.3.0-release? I don't give a damn about it! The idea release fast, release often is completely ridiculous in my eyes. Release early, release often?? Have you bothered to check when 4.2.0 came out? Let me refresh your memory: 22 Apr 2002. That's 8 months ago. For a point release. That is what's ridiculous. The next point release after 4.2.0 was 4.2.1. There are too many major changes in 4.3 vs. 4.2 to call it a 'point release'. Especially, there are still significant backwards compatibility bugs, such as http://bugs.php.net/bug.php?id=20441 - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Robin Thellend wrote: On Wed, 18 Dec 2002, Derick Rethans wrote: [...] I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. Derick Why don't you just add a simple check in the CLI code to exec() the CGI binary if it is called as a CGI? if(getenv(GATEWAY_INTERFACE) != NULL) execv(/path/to/php-cgi, argv); Lets not compound one bad idea with another. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Derick Rethans wrote: On Wed, 18 Dec 2002, Sebastian Nohn wrote: But renaming php-cli to php means renaming php to anything else (php-cgi, cgi-php, phpcgi, phpfoo, whatever), right? No, we didn't do that for 4.2.[0-3] either: [root@saturnus php-4.2.1]# ./configure --enable-cli [root@saturnus php-4.2.1]# make CGI: [root@saturnus php-4.2.1]# ls -l ./php -rwxr-xr-x1 root root 2915010 Dec 18 22:24 ./php CLI: [root@saturnus php-4.2.1]# ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 18 22:24 sapi/cli/php Isn't it only an issue on win32? In the 4.2.X win32 binaries php-cli has always been called php.exe and php-cli php-cli.exe. I just don't understand why this can't be left in win32 releases like it has been before - at least until 5.0. I'm sure there are not many cli users which on win32 - and if: these people are certainly not the beginners and they won't start filing bogus bug reports. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
I'm with Shane, that sounds like a really poor idea. On Wednesday, December 18, 2002, at 04:38 PM, Shane Caraveo wrote: Robin Thellend wrote: On Wed, 18 Dec 2002, Derick Rethans wrote: [...] I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. Derick Why don't you just add a simple check in the CLI code to exec() the CGI binary if it is called as a CGI? if(getenv(GATEWAY_INTERFACE) != NULL) execv(/path/to/php-cgi, argv); Lets not compound one bad idea with another. Shane -- 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] CGI and CLI
On Wed, 18 Dec 2002, Sascha Schumann wrote: The next point release after 4.2.0 was 4.2.1. There are too many major changes in 4.3 vs. 4.2 to call it a 'point release'. Semantics. Especially, there are still significant backwards compatibility bugs, such as http://bugs.php.net/bug.php?id=20441 Does everyone agree that it's a BC bug? If so, who is going to fix it? -Andrei http://www.gravitonic.com/ * if you hold a unix shell to your ear, do you hear the c? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Plain and simple, and it is the ONLY way that 4.3 can be released. There is no way in hell I would support the release of PHP with the cli binary replacing the cgi binary. Change it back to the way it was in 4.2.x since there is no time to properly fix the problem. Leave it marked experimental with a big note that the binary name may change in a later release. Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei http://www.gravitonic.com/ This isn't right. This isn't even wrong. -- Wolfgang Pauli -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. -Andrei http://www.gravitonic.com/ * Quantum Mechanics: The Dreams of Which Stuff is Made. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
I would agree that this is a big problem. Shane Andrei Zmievski wrote: On Wed, 18 Dec 2002, Sascha Schumann wrote: The next point release after 4.2.0 was 4.2.1. There are too many major changes in 4.3 vs. 4.2 to call it a 'point release'. Semantics. Especially, there are still significant backwards compatibility bugs, such as http://bugs.php.net/bug.php?id=20441 Does everyone agree that it's a BC bug? If so, who is going to fix it? -Andrei http://www.gravitonic.com/ * if you hold a unix shell to your ear, do you hear the c? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. I can agree to, and live with, this to some extent. The changes I would want on this would be... * On win32, cli remains php-cli.exe. Windows users can rename the executable if they feel it's necessary. * On other platforms, the cgi *is* installed by 'make install' by default. To install cli something like, 'make install-cli', or 'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the second option would be more usefull for installing both, using both without [DIR] on one results in a configure error). A note regarding what was installed and where should be added to the output resulting from an install. * Binaries are combined into a single binary in a later release. I'd be happy to do this in January. * Documentation is added in regards to this issue. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. Regards, Philip On Wed, 18 Dec 2002, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. -Andrei http://www.gravitonic.com/ * Quantum Mechanics: The Dreams of Which Stuff is Made. * -- 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] CGI and CLI
On Wed, 18 Dec 2002, Philip Olson wrote: So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. The merging of CLI and CGI will still happen, but in 4.3.1. -Andrei http://www.gravitonic.com/ * Marriage is not a word. It's a sentence. Life-long sentence. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Great. In that case, in order to make things a little smoother for users, could a little workaround like the one offered by Robin be considered ? On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Philip Olson wrote: So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. The merging of CLI and CGI will still happen, but in 4.3.1. -Andrei http://www.gravitonic.com/ * Marriage is not a word. It's a sentence. Life-long sentence. * -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use the correct PHP CGI binary.);
exit(1);
}
Xavier Spriet wrote:
Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?
On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Philip Olson wrote:
So every tutorial and documentation on this would have to
say this right?
Ask your sysadmin what the CGI and CLI versions of your
PHP are called, they could be anything as there is no
standard. For the purpose of this (tutorial|documentation),
we'll call CLI php-cli and CGI php-cgi.
Same goes for all cgi scripts, they'll work some places but
not others... And various RPM's would have different naming
schemes depending on the maintainers preference.
The merging of CLI and CGI will still happen, but in 4.3.1.
-Andrei http://www.gravitonic.com/
* Marriage is not a word. It's a sentence. Life-long sentence. *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Looks good enough for me, I don't see a problem with that.
On Wed, 2002-12-18 at 17:39, Shane Caraveo wrote:
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use the correct PHP CGI binary.);
exit(1);
}
Xavier Spriet wrote:
Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?
On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Philip Olson wrote:
So every tutorial and documentation on this would have to
say this right?
Ask your sysadmin what the CGI and CLI versions of your
PHP are called, they could be anything as there is no
standard. For the purpose of this (tutorial|documentation),
we'll call CLI php-cli and CGI php-cgi.
Same goes for all cgi scripts, they'll work some places but
not others... And various RPM's would have different naming
schemes depending on the maintainers preference.
The merging of CLI and CGI will still happen, but in 4.3.1.
-Andrei http://www.gravitonic.com/
* Marriage is not a word. It's a sentence. Life-long sentence. *
--
Xavier Spriet [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
The merging of CLI and CGI will still happen, but in 4.3.1. I was not under the impression that this decision has been reached. In fact there were several people strongly opposed to the idea and I'm one of them. I have several reasons one of them being that having an interpreter which radically changes behavior depending on environmental variables is a bad idea IMHO. In practice this would mean that one would be unable to run php command line scripts from within webserver environment, through system() call from other cgi/php scripts etc. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Andi Gutmans wrote:
I doubt this will happen fast enough. We should just release the way we
released 4.2.x, which as far as I know was php for CGI and php-cli for
CLI
or am I a bit behind things? :)
Derick and I hashed it out on IRC and we have a proposal:
We should keep 4.2.x behavior with some modifications. CLI and CGI
should always be built unless disabled, and the executables should go
into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install'
target should be modified to detect whether the user is trying to
install either one of these SAPIs, output a warning message regarding
the potential naming problem, and stop. Let the user install CLI and CGI
manually, basically.
I really hope we can come to an agreement on this.
I can agree to, and live with, this to some extent. The changes I would
want on this would be...
* On win32, cli remains php-cli.exe. Windows users can rename the
executable if they feel it's necessary.
I think that this is acceptable to everyone since in this way week keep
status quo to 4.2.x releases.
* On other platforms, the cgi *is* installed by 'make install' by
default. To install cli something like, 'make install-cli', or
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
second option would be more usefull for installing both, using both
without [DIR] on one results in a configure error). A note regarding
what was installed and where should be added to the output resulting
from an install.
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.
* Binaries are combined into a single binary in a later release. I'd be
happy to do this in January.
-1 for reasons i stated in my reply to Andrei.
* Documentation is added in regards to this issue.
Shane
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Edin Kadribasic wrote:
* On other platforms, the cgi *is* installed by 'make install' by
default. To install cli something like, 'make install-cli', or
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
second option would be more usefull for installing both, using both
without [DIR] on one results in a configure error). A note regarding
what was installed and where should be added to the output resulting
from an install.
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.
It's realy very logical. It leaves the default installation the way
most people will expect it to behave, which is as it has been for years
now. Having the options allow people to modify that behaviour to the
way they want it to work. It's very flexable for all interests.
* Binaries are combined into a single binary in a later release. I'd be
happy to do this in January.
-1 for reasons i stated in my reply to Andrei.
None of the reasons I have seen listed against this are insurmountable.
The *only* reason I have seen (ie. remember at this moment) that
comes close to convincing me otherwise is the one that you stated:
In practice this would mean that one would be unable to run php
command line scripts from within webserver environment, through system()
call from other cgi/php scripts etc.
The problem is that cli was started as a seperate binary and no thought
was put into having things work as a single binary. I'm not convinced
that there isn't a way around the system() issue yet...but you may have
a point. It could be done by using a flag in that instance (php -f
script.php for instance) but that is not optimal.
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Shane Caraveo wrote:
Edin Kadribasic wrote:
[snip]
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.
It's realy very logical. It leaves the default installation the way
most people will expect it to behave, which is as it has been for years
now. Having the options allow people to modify that behaviour to the
way they want it to work. It's very flexable for all interests.
This seems to be matter of personal opinion.
I happen to belive that having cli in /usr/bin/php is a real improvement
over having cgi there. For command line scripts cli is
(nearly) a drop-in replacement for cgi. I am not aware of webserver
installs that use cgi in that location.
My great wish was to have the same freedom perl programmers have in
distributing scripts with #!/usr/bin/perl shebang line. Scripts that you
could nearly count on being executable on the target host. And scripts
that would always work, no matter from which context they were called.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Cutting down on the list of receipients here... Philip please do not put this paragraph into the documentation. If there is any sure fire way to ensure that the latest version of PHP WON'T be installed on a system... it's to encourage end users to contact their system administrator. Although I don't have any better solution at this time... give me another 18 hours to free my brain of things and I might do much better at this. On Wednesday, December 18, 2002, at 05:16 PM, Philip Olson wrote: So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. Regards, Philip On Wed, 18 Dec 2002, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. -Andrei http://www.gravitonic.com/ * Quantum Mechanics: The Dreams of Which Stuff is Made. * -- 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 --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Dan Kalowsky wrote: Cutting down on the list of receipients here... Philip please do not put this paragraph into the documentation. If there is any sure fire way to ensure that the latest version of PHP WON'T be installed on a system... it's to encourage end users to contact their system administrator. Just FYI, I never intended to put that anywhere, it was more of a point to show how bad this can be. A support nightmare is to encourage sysadmins to name the binaries whatever they feel like, with no set standard. This sounds like PHP 4.3.0 I have no solution except that whatever decision is made can be implemented in 4.3.0. PHP 4.3.0 can wait an additional month or three. I see no reason why 4.3.0 should be pushed out the door just so 4.3.1 can implement this MAJOR change. It sounds like the two will be combined again, if so, make it so in PHP 4.3.0 please. Same goes for if it's decided to keep the two separate. Let the new RC series begin! :) Regards, Philip Olson [snip] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Shane Caraveo wrote: Andrei Zmievski wrote: Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. [...] * On other platforms, the cgi *is* installed by 'make install' by default. To install cli something like, 'make install-cli', or 'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the second option would be more usefull for installing both, using both without [DIR] on one results in a configure error). A note regarding what was installed and where should be added to the output resulting from an install. +1 on that * Binaries are combined into a single binary in a later release. I'd be happy to do this in January. Are you sure this is necessary? I think the above method solves everything AND we keep the binaries seperated for easier maintenance (for us). -- - 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] CGI and CLI
On 18 Dec 2002, Xavier Spriet wrote: Great. In that case, in order to make things a little smoother for users, could a little workaround like the one offered by Robin be considered ? No, as that is a very ugly thing to do IMO. 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] CGI and CLI
On Wed, 18 Dec 2002, Shane Caraveo wrote:
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use the correct PHP CGI binary.);
exit(1);
}
Don't forget the HTTP headers :)
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
