CGI and commandline setups

The default is to build PHP as a CGI program. This creates a commandline interpreter, which can be used for CGI processing, or for non-web-related PHP scripting. If you are running a web server PHP has module support for, you should generally go for that solution for performance reasons. However, the CGI version enables users to run different PHP-enabled pages under different user-ids.

Warning

By using the CGI setup, your server is open to several possible attacks. Please read our CGI security section to learn how to defend yourself from those attacks.

As of PHP 4.3.0, some important additions have happened to PHP. A new SAPI named CLI also exists and it has the same name as the CGI binary. What is installed at {PREFIX}/bin/php depends on your configure line and this is described in detail in the manual section named Using PHP from the command line. For further details please read that section of the manual.

Testing

If you have built PHP as a CGI program, you may test your build by typing make test. It is always a good idea to test your build. This way you may catch a problem with PHP on your platform early instead of having to struggle with it later.

Benchmarking

If you have built PHP 3 as a CGI program, you may benchmark your build by typing make bench. Note that if safe mode is on by default, the benchmark may not be able to finish if it takes longer then the 30 seconds allowed. This is because the set_time_limit() can not be used in safe mode. Use the max_execution_time configuration setting to control this time for your own scripts. make bench ignores the configuration file.

Note: make bench is only available for PHP 3.

Using Variables

Some server supplied environment variables are not defined in the current CGI/1.1 specification. Only the following variables are defined there: AUTH_TYPE, CONTENT_LENGTH, CONTENT_TYPE, GATEWAY_INTERFACE, PATH_INFO, PATH_TRANSLATED, QUERY_STRING, REMOTE_ADDR, REMOTE_HOST, REMOTE_IDENT, REMOTE_USER, REQUEST_METHOD, SCRIPT_NAME, SERVER_NAME, SERVER_PORT, SERVER_PROTOCOL, and SERVER_SOFTWARE. Everything else should be treated as 'vendor extensions'.

User Contributed Notes
CGI and commandline setups

kptrs at yahoo dot com
06-Jun-2004 07:37


Dug out from the discussion at the site below is a good tip: if you are working with an existing PHP installation which did not build either the commandline or CGI servers, you can use the lynx non-graphical web browser to get the web server to execute php scripts from the command line (or cron jobs, etc):



lynx -dump http://whatever



>If you wish to use PHP as a scripting language, a good article to read is >http://www.phpbuilder.com/columns/darrell20000319.php3



>note that the article is aimed at *nix not win32, but most of it still applies

phil at philkern dot de
03-Jan-2003 01:40


Thanks nordkyn, this one was very helpful.

Please note that the kernel has to be compiled with misc binary support, which is activated on most distributions like Debian.

You would have to please these two lines in a script to run it after every reboot, on debian I propose /etc/init.d/bootmisc.sh

You could place this lines at the end but before : exit 0

---

# Install PHP as binary handler



mount -t binfmt_misc none /proc/sys/fs/binfmt_misc

echo ":PHP:E::php::/usr/bin/php4:" > /proc/sys/fs/binfmt_misc/register

---

And please remember that the package management would override the file on the next distribution upgrade :)

nordkynNOSPAMPLZ at tin dot it
31-Jul-2002 08:49


Using a php4 cgi script with a non-Apache server (boa,thttpd,etc) leads to unexpected results:



#!/usr/local/bin/php

<?php

SOMETHING

?>



will work just fine from the command line but not when called from the web server.



The problem is that php4 expects to be called by an "Action" directive of

the server... unfortunately boa (and many others) does not support the action directive and calls the script directly.



HOW TO SOLVE: (works only with linux AFAIK)



you must compile your kernel with support for binfmt_misc then register php as a binary handler for php scripts



echo ":PHP:E::php::/usr/local/bin/php:" > /proc/sys/fs/binfmt_misc/register



and remove the #!/usr/local/bin/php line in your script



NOTE:

for recent 2.4.x kernels you must mount binfmt_misc



mount -t binfmt_misc none /proc/sys/fs/binfmt_misc

ben-php dot net at efros dot com
13-Jun-2002 06:41


PHP 4.3 and above automatically have STDOUT, STDIN, and STDERR openned ... but < 4.3.0 do not.  This is how you make code that will work in versions previous to PHP 4.3 and future versions without any changes:



    if (version_compare(phpversion(),'4.3.0','<')) {

        define('STDIN',fopen("php://stdin","r"));

define('STDOUT',fopen("php://stout","r"));

define('STDERR',fopen("php://sterr","r"));

        register_shutdown_function( create_function( '' , 'fclose(STDIN); fclose(STOUT); fclose(STERR); return true;' ) );

    }



/* get some STDIN up to 256 bytes */

    $str = fgets(STDIN,256);

cv at corbach dot de
20-Feb-2002 11:18


Up to and including 4.1.1 you have to set doc_root to an non empty value if you configure PHP for CGI usage with --enable-discard-path.