Php Cli?

I have a stage server with mod_php, php-cgi, and php (CLI). In a photography sales system I am working on, I check for php_sapi_name() == ‘cli’ to determine if the PHP script is being running from the command line (these are maintenance scripts called by cron, and never by the web browser). My command is:

php cron.php

On my stage box, it works, but on my InterWorx box the conditional fails and php_sapi_name() returns ‘cgi’. Why is “php” actually the CGI version of PHP (it is normally “php-cgi” AFAIK), and the CLI version of PHP not even available?

Note: This app is supposed to be easy to install, by extracting a tar/zip and editing a configuration file. Moving the cron scripts out of the web path is not an option IMO because it adds complications to the user install/application. Some users wouldn’t bother to move them anyway. Plus some of these “maintenance” scripts actually can be called from a browser…

So what are my options? Do I need to recompile the PHP RPM? What effect will this have on InterWorx?

So what are my options? Do I need to recompile the PHP RPM? What effect will this have on InterWorx?

When building PHP you have the option to do the CLI or CGI command line versions. We chose CGI since the bulk of folks will need/want/use it. To use the CLI by default you’ll need to recompile the RPM and specify that you want to build the CLI instead jimp.

Chris

Hmmm… I am reading now that CLI and CGI both produce the same binary name, so I guess that means you can’t have both. If I dump CGI for CLI, is InterWorx-CP going to be upset?

I’m a little confused. Why would anyone want PHP CGI if mod_php is faster/more efficient? I figured the PHP CGI was only provided for internal use with InterWorx…

Does anyone have a good (and portable) method for detecting non-webserver PHP execution? My problem doesn’t mandate that I have PHP CLI installed if there is a simple alternative method to php_sapi_name().

Hmmm… I am reading now that CLI and CGI both produce the same binary name, so I guess that means you can’t have both. If I dump CGI for CLI, is InterWorx-CP going to be upset?

InterWorx-CP doesn’t use or care about the PHP version installed the system so you can safely change/delete/mess-with it :).

I’m a little confused. Why would anyone want PHP CGI if mod_php is faster/more efficient?

The CGI php bin can come in handy in spots where mod_php isn’t available (i.e. in CGI only environments). It’s also nice because with suexec installed PHP scripts run as the user and not the webserver.

I figured the PHP CGI was only provided for internal use with InterWorx…

Nope, it’s part of the default php installation and we chose CGI over CLI for the reasons above.

InterWorx-CP uses the CLI version of PHP for it’s own internal stuff as well as mod_php, but this is all self-contained to InterWorx-CP and doesn’t correspond to /usr/bin/php or the mod_php installed with the system Apache.

Does anyone have a good (and portable) method for detecting non-webserver PHP execution? My problem doesn’t mandate that I have PHP CLI installed if there is a simple alternative method to php_sapi_name().

jimp, the return val should consistent contain the chars cli or cgi when running in a non-webserver env. We use that check and it’s the best one I know of.

Chris

So running PHP CGI through Apache will not return “cgi”? It will return something else? Oops… :o I just always thought PHP CGI would return the same SAPI name, no matter who executes it (me at the command line, Apache, IIS, etc).

I’ll give it a try and let you know if my results are contrary to your suggestion. Thanks!

So running PHP CGI through Apache will not return “cgi”? It will return something else?

It should return: “apache” or somehting similar

Oops… I just always thought PHP CGI would return the same SAPI name, no matter who executes it (me at the command line, Apache, IIS, etc).

nope :), luckily.

Chris