downloads | documentation | faq | getting help | mailing lists | reporting bugs | sites | links | my 
search for in the  
<Functions restricted/disabled by safe modeFunction Reference>
view the version of this page
Last updated: Thu, 21 Aug 2003

Chapter 23. Using PHP from the command line

As of version 4.3.0, PHP supports a new SAPI type (Server Application Programming Interface) named CLI which means Command Line Interface. As the name implies, this SAPI type main focus is on developing shell (or desktop as well) applications with PHP. There are quite a few differences between the CLI SAPI and other SAPIs which are explained in this chapter. It's worth mentioning that CLI and CGI are different SAPI's although they do share many of the same behaviors.

The CLI SAPI was released for the first time with PHP 4.2.0, but was still experimental and had to be explicitly enabled with --enable-cli when running ./configure. Since PHP 4.3.0 the CLI SAPI is no longer experimental and the option --enable-cli is on by default. You may use --disable-cli to disable it.

As of PHP 4.3.0, the name, location and existence of the CLI/CGI binaries will differ depending on how PHP is installed on your system. By default when executing make, both the CGI and CLI are built and placed as sapi/cgi/php and sapi/cli/php respectively, in your php source directory. You will note that both are named php. What happens during make install depends on your configure line. If a module SAPI is chosen during configure, such as apxs, or the --disable-cgi option is used, the CLI is copied to {PREFIX}/bin/php during make install otherwise the CGI is placed there. So, for example, if --with--apxs is in your configure line then the CLI is copied to {PREFIX}/bin/php during make install. If you want to override the installation of the CGI binary, use make install-cli after make install. Alternatively you can specify --disable-cgi in your configure line.

Note: Because both --enable-cli and --enable-cgi are enabled by default, simply having --enable-cli in your configure line does not necessarily mean the CLI will be copied as {PREFIX}/bin/php during make install.

The windows packages between PHP 4.2.0 and PHP 4.2.3 distributed the CLI as php-cli.exe, living in the same folder as the CGI php.exe. Starting with PHP 4.3.0 the windows package distributes the CLI as php.exe in a separate folder named cli, so cli/php.exe.

What SAPI do I have?: From a shell, typing php -v will tell you whether php is CGI or CLI. See also the function php_sapi_name() and the constant PHP_SAPI.

Note: A unix manual page was added in PHP 4.3.2. You may view this by typing man php in your shell environment.

Remarkable differences of the CLI SAPI compared to other SAPIs:

  • Unlike the CGI SAPI, no headers are written to the output.

    Though the CGI SAPI provides a way to suppress HTTP headers, there's no equivalent switch to enable them in the CLI SAPI.

    CLI is started up in quiet mode by default, though the -q switch is kept for compatibility so that you can use older CGI scripts.

    It does not change the working directory to that of the script. (-C switch kept for compatibility)

    Plain text error messages (no HTML formatting).

  • There are certain php.ini directives which are overriden by the CLI SAPI because they do not make sense in shell environments:

    Table 23-1. Overriden php.ini directives

    DirectiveCLI SAPI default valueComment
    html_errorsFALSE It can be quite hard to read the error message in your shell when it's cluttered with all those meaningless HTML tags, therefore this directive defaults to FALSE.
    implicit_flushTRUE It is desired that any output coming from print(), echo() and friends is immediately written to the output and not cached in any buffer. You still can use output buffering if you want to defer or manipulate standard output.
    max_execution_time0 (unlimited) Due to endless possibilities of using PHP in shell environments, the maximum execution time has been set to unlimited. Whereas applications written for the web are often executed very quickly, shell application tend to have a much longer execution time.

    Because this setting is TRUE you will always have access to argc (number of arguments passed to the application) and argv (array of the actual arguments) in the CLI SAPI.

    As of PHP 4.3.0, the PHP variables $argc and $argv are registered and filled in with the appropriate values when using the CLI SAPI. Prior to this version, the creation of these variables behaved as they do in CGI and MODULE versions which requires the PHP directive register_globals to be on. Regardless of version or register_globals setting, you can always go through either $_SERVER or $HTTP_SERVER_VARS. Example: $_SERVER['argv']

    Note: These directives cannot be initialized with another value from the configuration file php.ini or a custom one (if specified). This is a limitation because those default values are applied after all configuration files have been parsed. However, their value can be changed during runtime (which does not make sense for all of those directives, e.g. register_argc_argv).

  • To ease working in the shell environment, the following constants are defined:

    Table 23-2. CLI specific Constants

    STDIN An already opened stream to stdin. This saves opening it with
    $stdin = fopen('php://stdin', 'r');
    STDOUT An already opened stream to stdout. This saves opening it with
    $stdout = fopen('php://stdout', 'w');
    STDERR An already opened stream to stderr. This saves opening it with
    $stderr = fopen('php://stderr', 'w');

    Given the above, you don't need to open e.g. a stream for stderr yourself but simply use the constant instead of the stream resource:
    php -r 'fwrite(STDERR, "stderr\n");'
    You do not need to explicitly close these streams, as they are closed automatically by PHP when your script ends.

  • The CLI SAPI does not change the current directory to the directory of the executed script!

    Example showing the difference to the CGI SAPI:
        /* Our simple test application named test.php*/
        echo getcwd(), "\n";

    When using the CGI version, the output is:
    $ pwd
    $ php -q another_directory/test.php
    This clearly shows that PHP changes its current directory to the one of the executed script.

    Using the CLI SAPI yields:
    $ pwd
    $ php -f another_directory/test.php
    This allows greater flexibility when writing shell tools in PHP.

    Note: The CGI SAPI supports the CLI SAPI behaviour by means of the -C switch when run from the command line.

The list of command line options provided by the PHP binary can be queried anytime by running PHP with the -h switch:
Usage: php [options] [-f] <file> [args...]
       php [options] -r <code> [args...]
       php [options] [-- args...]
  -s               Display colour syntax highlighted source.
  -w               Display source with stripped comments and whitespace.
  -f <file>        Parse <file>.
  -v               Version number
  -c <path>|<file> Look for php.ini file in this directory
  -a               Run interactively
  -d foo[=bar]     Define INI entry foo with value 'bar'
  -e               Generate extended information for debugger/profiler
  -z <file>        Load Zend extension <file>.
  -l               Syntax check only (lint)
  -m               Show compiled in modules
  -i               PHP information
  -r <code>        Run PHP <code> without using script tags <?..?>
  -h               This help

  args...          Arguments passed to script. Use -- args when first argument 
                   starts with - or script is read from stdin

The CLI SAPI has three different ways of getting the PHP code you want to execute:

  1. Telling PHP to execute a certain file.

    php my_script.php
    php -f my_script.php
    Both ways (whether using the -f switch or not) execute the file my_script.php. You can choose any file to execute - your PHP scripts do not have to end with the .php extension but can have any name or extension you wish.

  2. Pass the PHP code to execute directly on the command line.

    php -r 'print_r(get_defined_constants());'
    Special care has to be taken in regards of shell variable substitution and quoting usage.

    Note: Read the example carefully, there are no beginning or ending tags! The -r switch simply does not need them. Using them will lead to a parser error.

  3. Provide the PHP code to execute via standard input (stdin).

    This gives the powerful ability to dynamically create PHP code and feed it to the binary, as shown in this (fictional) example:
    $ some_application | some_filter | php | sort -u >final_output.txt

You cannot combine any of the three ways to execute code.

Like every shell application, the PHP binary accepts a number of arguments but your PHP script can also receive arguments. The number of arguments which can be passed to your script is not limited by PHP (the shell has a certain size limit in the number of characters which can be passed; usually you won't hit this limit). The arguments passed to your script are available in the global array $argv. The zero index always contains the script name (which is - in case the PHP code is coming from either standard input or from the command line switch -r). The second registered global variable is $argc which contains the number of elements in the $argv array (not the number of arguments passed to the script).

As long as the arguments you want to pass to your script do not start with the - character, there's nothing special to watch out for. Passing an argument to your script which starts with a - will cause trouble because PHP itself thinks it has to handle it. To prevent this, use the argument list separator --. After this separator has been parsed by PHP, every argument following it is passed untouched to your script.

# This will not execute the given code but will show the PHP usage
$ php -r 'var_dump($argv);' -h
Usage: php [options] [-f] <file> [args...]

# This will pass the '-h' argument to your script and prevent PHP from showing it's usage
$ php -r 'var_dump($argv);' -- -h
array(2) {
  string(1) "-"
  string(2) "-h"

However, there's another way of using PHP for shell scripting. You can write a script where the first line starts with #!/usr/bin/php. Following this you can place normal PHP code included within the PHP starting and end tags. Once you have set the execution attributes of the file appropriately (e.g. chmod +x test) your script can be executed like a normal shell or perl script:
Assuming this file is named test in the current directory, we can now do the following:
$ chmod 755 test
$ ./test -h -- foo
array(4) {
  string(6) "./test"
  string(2) "-h"
  string(2) "--"
  string(3) "foo"
As you see, in this case no care needs to be taken when passing parameters which start with - to your script.

Table 23-3. Command line options


Display colour syntax highlighted source.

This option uses the internal mechanism to parse the file and produces a HTML highlighted version of it and writes it to standard output. Note that all it does it to generate a block of <code> [...] </code> HTML tags, no HTML headers.

Note: This option does not work together with the -r option.


Display source with stripped comments and whitespace.

Note: This option does not work together with the -r option.


Parses and executed the given filename to the -f option. This switch is optional and can be left out. Only providing the filename to execute is sufficient.


Writes the PHP, PHP SAPI, and Zend version to standard output, e.g.
$ php -v
PHP 4.3.0 (cli), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies


With this option one can either specify a directory where to look for php.ini or you can specify a custom INI file directly (which does not need to be named php.ini), e.g.:
$ php -c /custom/directory/ my_script.php

$ php -c /custom/directory/custom-file.ini my_script.php


Runs PHP interactively.


This option allows you to set a custom value for any of the configuration directives allowed in php.ini. The syntax is:
-d configuration_directive[=value]

Examples (lines are wrapped for layout reasons):
# Omitting the value part will set the given configuration directive to "1"
$ php -d max_execution_time
        -r '$foo = ini_get("max_execution_time"); var_dump($foo);'
string(1) "1"

# Passing an empty value part will set the configuration directive to ""
php -d max_execution_time=
        -r '$foo = ini_get("max_execution_time"); var_dump($foo);'
string(0) ""

# The configuration directive will be set to anything passed after the '=' character
$  php -d max_execution_time=20
        -r '$foo = ini_get("max_execution_time"); var_dump($foo);'
string(2) "20"
$  php
        -d max_execution_time=doesntmakesense
        -r '$foo = ini_get("max_execution_time"); var_dump($foo);'
string(15) "doesntmakesense"


Generate extended information for debugger/profiler.


Load Zend extension. If only a filename is given, PHP tries to load this extension from the current default library path on your system (usually specified /etc/ on Linux systems). Passing a filename with an absolute path information will not use the systems library search path. A relative filename with a directory information will tell PHP only to try to load the extension relative to the current directory.


This option provides a convenient way to only perform a syntax check on the given PHP code. On succes, the text No syntax errors detected in <filename> is written to standard output and the shell return code is 0. On failure, the text Errors parsing <filename> in addition to the internal parser error message is written to standard output and the shell return code is set to 255.

This option won't find fatal errors (like undefined functions). Use -f if you would like to test for fatal errors too.

Note: This option does not work together with the -r option.


Using this option, PHP prints out the built in (and loaded) PHP and Zend modules:
$ php -m
[PHP Modules]

[Zend Modules]

-i This command line option calls phpinfo(), and prints out the results. If PHP is not working correctly, it is advisable to use php -i and see whether any error messages are printed out before or in place of the information tables. Beware that the output is in HTML and therefore quite huge.

This option allows execution of PHP right from within the command line. The PHP start and end tags (<?php and ?>) are not needed and will cause a parser error if present.

Note: Care has to be taken when using this form of PHP to not collide with command line variable substitution done by the shell.

Example showing a parser error
$ php -r "$foo = get_defined_constants();"
Command line code(1) : Parse error - parse error, unexpected '='
The problem here is that the sh/bash performs variable substitution even when using double quotes ". Since the variable $foo is unlikely to be defined, it expands to nothing which results in the code passed to PHP for execution actually reading:
$ php -r " = get_defined_constants();"
The correct way would be to use single quotes '. Variables in single-quoted strings are not expanded by sh/bash.
$ php -r '$foo = get_defined_constants(); var_dump($foo);'
array(370) {
If you are using a shell different from sh/bash, you might experience further issues. Feel free to open a bug report or send a mail to One can still easily run into troubles when trying to get shell variables into the code or using backslashes for escaping. You've been warned.

Note: -r is available in the CLI SAPI and not in the CGI SAPI.

-h With this option, you can get information about the actual list of command line options and some one line descriptions about what they do.

The PHP executable can be used to run PHP scripts absolutely independent from the web server. If you are on a Unix system, you should add a special first line to your PHP script, and make it executable, so the system will know, what program should run the script. On a Windows platform you can associate php.exe with the double click option of the .php files, or you can make a batch file to run the script through PHP. The first line added to the script to work on Unix won't hurt on Windows, so you can write cross platform programs this way. A simple example of writing a command line PHP program can be found below.

Example 23-1. Script intended to be run from command line (script.php)


if ($argc != 2 || in_array($argv[1], array('--help', '-help', '-h', '-?'))) {

This is a command line PHP script with one option.

  <?php echo $argv[0]; ?> <option>

  <option> can be some word you would like
  to print out. With the --help, -help, -h,
  or -? options, you can get this help.

} else {
    echo $argv[1];

In the script above, we used the special first line to indicate that this file should be run by PHP. We work with a CLI version here, so there will be no HTTP header printouts. There are two variables you can use while writing command line applications with PHP: $argc and $argv. The first is the number of arguments plus one (the name of the script running). The second is an array containing the arguments, starting with the script name as number zero ($argv[0]).

In the program above we checked if there are less or more than one arguments. Also if the argument was --help, -help, -h or -?, we printed out the help message, printing the script name dynamically. If we received some other argument we echoed that out.

If you would like to run the above script on Unix, you need to make it executable, and simply call it as script.php echothis or script.php -h. On Windows, you can make a batch file for this task:

Example 23-2. Batch file to run a command line PHP script (script.bat)

@c:\php\cli\php.exe script.php %1 %2 %3 %4

Assuming you named the above program script.php, and you have your CLI php.exe in c:\php\cli\php.exe this batch file will run it for you with your added options: script.bat echothis or script.bat -h.

See also the Readline extension documentation for more functions you can use to enhance your command line applications in PHP.

add a note add a note User Contributed Notes
Using PHP from the command line
phprsr at mindtwin dot com
06-Aug-2003 11:12
The basic issue was that PHP-as-CGI REALLY REALLY wants SCRIPT_FILENAME.
It ignores the command line. It ignores SCRIPT_NAME.  It wants

"No input file specified."

This very informative error message from PHP means that your web server, WHATEVER it is, is not setting SCRIPT_FILENAME.

The minimum set of env variables:

PATH: DOESN'T MATTER if you're spawning php pages with #!/../php in them
LD_LIBRARY_PATH= should be right
SERVER_SOFTWARE=mini_httpd/1.17beta1 26may2002
SERVER_NAME=who cares
SCRIPT_FILENAME=/homes/foobie/mini/foo.php    <--- CRITICAL
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

If SCRIPT_FILENAME is not set, you'll get the dreaded "No input file specified" message.

mini_httpd does not do this by default. You need to patch it in to make_envp.

A secondary issue is configuration (PHP):

    ./configure --enable-discard-path --with-config-file-path=/homes/wherever/mini/php.ini
    (where php.ini is a slightly modified version of php.ini-recommended)
punk [_at_] studionew [_dot_] com
19-Jul-2003 06:18
You can use this function to ask user to enter smth

function read ($length='255')
   if (!isset (
$GLOBALS['StdinPointer'] = fopen ("php://stdin","r");
$line fgets ($GLOBALS['StdinPointer'],$length);
trim ($line);

// then

echo "Enter your name: ";
$name read ();
"\nHello $name! Where you came from? ";
$where read ();
"\nI see. $where is very good place.";
Adam, php(at)
17-Jun-2003 06:12
Ok, I've had a heck of a time with PHP > 4.3.x and whether to use CLI vs CGI. The CGI version of 4.3.2 would return (in browser):
No input file specified.

And the CLI version would return:
500 Internal Server Error

It appears that in CGI mode, PHP looks at the environment variable PATH_TRANSLATED to determine the script to execute and ignores command line. That is why in the absensce of this environment variable, you get "No input file specified." However, in CLI mode the HTTP headers are not printed. I believe this is intended behavior for both situations but creates a problem when you have a CGI wrapper that sends environment variables but passes the actual script name on the command line.

By modifying my CGI wrapper to create this PATH_TRANSLATED environment variable, it solved my problem, and I was able to run the CGI build of 4.3.2
monte at ispi dot net
05-Jun-2003 05:47
I had a problem with the $argv values getting split up when they contained plus (+) signs. Be sure to use the CLI version, not CGI to get around it.

Popeye at P-t-B dot com
18-Apr-2003 10:15
In *nix systems, use the WHICH command to show the location of the php binary executable. This is the path to use as the first line in your php shell script file. (#!/path/to/php -q) And execute php from the command line with the -v switch to see what version you are running.


# which php
# php -v
PHP 4.3.1 (cli) (built: Mar 27 2003 14:41:51)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

In the above example, you would use: #!/usr/local/bin/php

Also note that, if you do not have the current/default directory in your PATH (.), you will have to use ./scriptfilename to execute your script file from the command line (or you will receive a "command not found" error). Use the ENV command to show your PATH environment variable value.
volkany at celiknet dot com
21-Feb-2003 05:44
Here goes a very simple clrscr function for newbies...
function clrscr() { system("clear"); }
Alexander Plakidin
14-Feb-2003 09:34
How to change current directory in PHP script to script's directory when running it from command line using PHP 4.3.0?
(you'll probably need to add this to older scripts when running them under PHP 4.3.0 for backwards compatibility)

Here's what I am using:

Note: documentation says that "PHP_SELF" is not available in command-line PHP scripts. Though, it IS available. Probably this will be changed in future version, so don't rely on this line of code...

Use $_SERVER['PHP_SELF'] instead of just $PHP_SELF if you have register_globals=Off
c dot kelly[no--spam] at qfsaustrlia dot com dot au
07-Feb-2003 12:03
In Windows [NT4.0 sp6a] the example
php -r ' echo getcwd();' does not work ; It appears you have to use the following php -r "echo getcwd();" --not the " around the command   to get the output to screen , just took me half an hour to figure out what was going on.
wanna at stay dot anonynous dot com
23-Jan-2003 01:42
TIP: If you want different versions of the configuration file  depending on what SAPI is used,just name them php.ini (apache module), php-cli.ini (CLI) and php-cgi.ini (CGI) and dump them all in the regular configuration directory. I.e no need to compile several versions of php anymore!
chris at free-source dot com
21-Jan-2003 06:23
The php binary that come with Mandrake (tested with 7.2, 8.2, 9.0) seems to not support -r <code>.  -r is not listed when running php -h and it gives you the -h if you try to use -r.
stuartc1 at hotmail dot com
14-Jan-2003 02:18
If you have an older version of PHP (for example 4.1.2 as I have have), and trying to execute a script from the windows NT command line then try this:

>c:\php\php -q c:\file_to_execute.php

note that you may need to execute from withing your php.exe directory as above. remeber to put the full path to the script you want to execute. The -q means quite mode and suppressed headers, you could also try -f or with no switches at all.
limberg at nospam dot grebmil dot port5 dot com
11-Jan-2003 07:39
The manual keeps referring to c:\php\cli\php.exe for windows.  I have no "cli" directory so I just tried c:\php\php.exe in my .bat file.  Not sure what the difference is but it seems to work fine on Win98 SE without any server installed or running.  Just though it might help someone.
mbostrom at paragee dot com
19-Nov-2002 03:47
[Ed note: The manual says nothing about $argv/$argc.  In a SAPI other than CLI, $argv/$argc variables existing depends on the register_globals directive.]

The PHP manual states that register_argc_argv causes the _global_ variables $argc and $argv to be registered.

However, with PHP 4.2.2, setting register_argc_argv causes $_SERVER["argc"] and $_SERVER["argv"] to be set.  The globals $argc and $argv ARE NOT SET.
phpnotes at ssilk dot de
22-Oct-2002 05:36
To hand over the GET-variables in interactive mode like in HTTP-Mode (e.g. your URI is myprog.html?hugo=bla&bla=hugo), you have to call

php myprog.html '&hugo=bla&bla=hugo'

(two & instead of ? and &!)

There just a little difference in the $ARGC, $ARGV values, but I think this is in those cases not relevant.
justin at visunet dot ie
21-Oct-2002 11:21
If you are trying to set up an interactive command line script and you want to get started straight away (works on 4+ I hope). Here is some code to start you off:


// Stop the script giving time out errors..

// This opens standard in ready for interactive input..

// Main event loop to capture top level command..
// Print out main menu..
echo "Select an option..\n\n";
"    1) Do this\n";
"    2) Do this\n";
"    3) Do this\n";
"    x) Exit\n";

// Decide what menu option to select based on input..




// Close standard in..

phpNOSPAM at dogpoop dot cjb dot net
12-Oct-2002 10:28
Here are some instructions on how to make PHP files executable from the command prompt in Win2k.  I have not tested this in any other version of Windows, but I'm assuming it will work in XP, but not 9x/Me.

There is an environment variable (control panel->system->advanced->environment variables) named PATHEXT.  This is a list of file extensions Windows will recognize as executable at the command prompt.  Add .PHP (or .PL, or .CLASS, or whatever) to this list.  Windows will use the default action associated with that file type when you execute it from the command prompt.

To set up the default action:
Open Explorer.
Go to Tools->folder options->file types
Find the extension you're looking for.  If it's not there, click New to add it.
Click on the file type, then on Advanced, then New.
For the action, type "Run" or "Execute" or whatever makes sense.
For the application, type
  {path to application} "%1" %*
The %* will send any command line options that you type to the program.
The application field for PHP might look like
  c:\php\php.exe -f "%1" -- %*
(Note, you'll probably want to use the command line interface version php-cli.exe)
or for Java
  c:\java\java.exe "%1" %*
Click OK.
Click on the action that was just added, then click Set default.

If this helps you or if you have any changes/more information I would appreciate a note.  Just remove NOSPAM from the email address.
jeff at noSpam[] dot genhex dot net
06-Sep-2002 07:13
You can also call the script from the command line after chmod'ing the file (ie: chmod 755 file.php).

On your first line of the file, enter "#!/usr/bin/php" (or to wherever your php executable is located).  If you want to suppress the PHP headers, use the line of "#!/usr/bin/php -q" for your path.
16-Aug-2002 01:15
Under Solaris (at least 2.6) I have some problems with reading stdin. Original pbms report may be found here:

At a first glance the only solution for it is 'fgetcsv'

#!/usr/local/bin/php -q

if (!

while (!
feof ($fd))
$s fgetcsv($fd,128,"\n");
  if (


But... keep reading....

>>> I wrote
Sometimes I hate PHP... ;)

Right today I was trapped by some strange bug in my code with reading stdin using fgetcsv.
After a not small investigation I found that strings like "foo\nboo\ndoo"goo\n (take note of double quatation sign in it)
interpreted by fgetcsv like:
since double quotation mark has a special meaning and get stripped off of the input stream.
Indeed, according to PHP manual:
array fgetcsv ( int fp, int length [, string delimiter [, string enclosure]])

another delimiter with the optional third parameter. _The_enclosure_character_is_double_quote_,_unless_
_enclosure_is_added_from_PHP 4.3.0.       !!!!!!

Means no chance for us prior to 4.3.0 :(
But file() works just fine !!!! Of course by the price of memory, so be careful with large files.

set_magic_quotes_runtime(0); // important, do not forget it !!!
for ($i=0,$n=sizeof($s);$i<$n;$i++)

1. If you have no double quotation mark in your data use fgetcsv
2. From 4.3.0 use   fgetcsv($fd,"\n",""); // I hope it will help
3. If you data is not huge use file("php://stdin");

Hope now it's cleared for 100% (to myself ;)

Good luck!

PS. Don't forget that it's only Solaris specific problem. Under Linux just use usual fgets()...
jonNO at SPAMjellybob dot co dot uk
04-Aug-2002 11:17
If you want to get the output of a command use the function shell_exec($command) - it returns a string with the output of the command.
vboctor at hotmail dot com
27-Jun-2002 05:52
You will only be able to use $argc and $argv if you have in php.ini:
register_globals = On
register_argc_argv = On

If you have register_globals = Off, then you should use $_SERVER['argc'] and $_SERVER['argv'][0]. (recommended approach)

Also for some reason php "-c /my/path/php.ini" did not work for me.  I had to use "php -c /my/path/" which looks for php.ini in the specified path.  This is for PHP 4.2.1 (compiled under FreeBSD).
15-Jun-2002 02:46
a few missing d's in the handy function. here it is with the typos fixed

if (version_compare(phpversion(),'4.3.0','<'))
        register_shutdown_function( create_function( '' , 'fclose(STDIN);
        fclose(STDOUT); fclose(STDERR); return true;' ) );
ben-php dot net at wefros dot com
14-Jun-2002 05:40
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','<')) {
        register_shutdown_function( create_function( '' , 'fclose(STDIN); fclose(STOUT); fclose(STERR); return true;' ) );

/* get some STDIN up to 256 bytes */
    $str = fgets(STDIN,256);

<Functions restricted/disabled by safe modeFunction Reference>
 Last updated: Thu, 21 Aug 2003
show source | credits | sitemap | mirror sites 
Copyright © 2001-2003 The PHP Group
All rights reserved.
This mirror generously provided by:
Last updated: Sat 01 Nov 2003 04:13:36 EST EST