On Tue, 10 Dec 2002, Zeev Suraski wrote:
> I think that's a bit like inventing problems and then trying to fix them.
> Let's keep it down to things we can determine relatively easily:
>
> - Nothing bad will happen if we name the new CLI with whatever kind of name
> - php-cli, phpsh, whatever
> - There WILL be some level of confusion if we rename the CGI binary
>
> If we use this KISS approach, why the heck are we even considering this rename?
The CGI sapi was first renamed to php-cgi on Feb 28, and the change was
temporarily reverted for the 4.2.x release because CLI sapi was
considered experimental.
The reason for the name change was discussed on php-dev back then and it
had to do with the fact that most people felt that "make install" should
install CLI in ${PREFIX}/bin/php. The goal was to make the php interpreter
installed on as many machines as possible. And for the reasons of keeping
BC CLI sapi was named php so that existing scripts that have
#!/usr/bin/php shebang line would not have to be modified. For the same
reason CLI silently ignores some command line options (like -q and -C).
The next logical questions was what to do with the CGI sapi. It made very
little sense to "make install" it under the same name in some different
folder, so a decision was reached to rename it to php-cgi. "make install"
and cgi make very little sense anyway since the installer has no way of
knowing what's the correct location for the binary. Configuring a server
for execution of php as a cgi requires manual configuration anyway.
Windows file rename merely mirrored that of the unix build.
I'm still of the oppinion that we should leave things as they are in PHP
4.3.0-dev for the reasons stated.
Edin
P.S. I wish people were following this list more closely so that we don't
have to discuss same issues over and over again.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
