> [snip]
>
> Look, IMHO, it all boils down to the same simple points:
> - No drawbacks to naming the PHP CLI as something different than
PHP (well,
> unless you count the gut feeling of people who 'feel make install
should
> install CLI in ${PREFIX}/bin/php', without really being able to
say why).
> - Considerable drawbacks to changing the PHP CGI name. You may
argue that
> the confusion this would cause is not as bad as I may think, but
you cannot
> argue that it won't cause confusion. I'm a fairly competent user,
and it
> still took me a few minutes to understand what was going on and
> why. Suffice to say I came across less competent users.
The big drawback for me is the BC issue of changing all the command
line scripts that contain #!/usr/bin/php in them. I still see no
sense in putting a CGI binary there. Configuring a web server for
running CGI involves manual copy of the PHP binary anyway.
> >P.S. I wish people were following this list more closely so that
we don't
> >have to discuss same issues over and over again.
>
> Unfortunately this is not an option for all of us at any given
time.
> I, for one, do wish that the developers here employed a more
user-oriented
> approach and less 'this should be changed cause it'll be
cool/neat/Right'
> approach. This would do a lot of good for PHP.
I don't claim to hold a monopoly on what is a user-oriented
approach. I'd sure like to think that the changes implemented are
for the good of the user. Not because they're "cool/neat/Right".
I agree that most of development done in PHP is geared towards the
web. That's what I do for living as well. But in the past 3 years
and about a dozen or so rather large PHP solutions later, I see that
the command line scripting mustn't be neglected either. Why write
backend processes in language other than PHP? Once we have developed
all the classes/libraries for the web solution it is obvious that
the easiest way to implemet the rest of the system is to re-use
those in command line (often run from cron) PHP scripts. And from
what I hear from other development houses, my experiences are far
from unique.
Edin
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
