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-cgi 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.

Забележка:
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
. Starting with PHP 5, the CLI is distributed in the main folder,
named php.exe. The CGI version is distributed as
php-cgi.exe.

As of PHP 5, a new php-win.exe file is distributed.
This is equal to the CLI version, except that php-win doesn't output
anything and thus provides no console (no "dos box" appears on the screen).
This behavior is similar to php-gtk. You should configure with
--enable-cli-win32.

Забележка:
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.

Забележка:
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
and --no-header switches are kept for compatibility so
that you can use older CGI scripts.

It does not change the working directory to that of the script.
(-C and --no-chdir switches kept for
compatibility)

Plain text error messages (no HTML formatting).

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

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.

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']

Забележка:
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:

CLI specific Constants

Constant

Description

STDIN

An already opened stream to stdin. This saves
opening it with

<?php

$stdin = fopen('php://stdin', 'r');

?>

If you want to read single line from stdin, you can
use

<?php$line = trim(fgets(STDIN)); // reads one line from STDINfscanf(STDIN, "%d\n", $number); // reads number from STDIN?>

STDOUT

An already opened stream to stdout. This saves
opening it with

<?php

$stdout = fopen('php://stdout', 'w');

?>

STDERR

An already opened stream to stderr.
This saves opening it with

<?php

$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.

Забележка:
These constants are not available in case of reading PHP script from
stdin.

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

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

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.

Забележка:
If you need to pass arguments to your scripts you need to pass
-- as the first argument when using the
-f switch.

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.

Забележка:
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.

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.

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:

Example #1 Execute PHP script as shell script

#!/usr/bin/php<?phpvar_dump($argv);?>

Assuming this file is named test in the current
directory, we can now do the following:

As you see, in this case no care needs to be taken when passing parameters
which start with - to your script.

Long options are available since PHP 4.3.3.

Command line options

Option

Long Option

Description

-a

--interactive

Runs PHP interactively. If you compile PHP with the Readline extension (which is not
available on Windows), you'll have a nice shell, including a
completion feature (e.g. you can start typing a variable name, hit the
TAB key and PHP completes its name) and a typing history that can be
accessed using the arrow keys. The history is saved in the
~/.php_history file.

Забележка:
Files included through auto_prepend_file and auto_append_file are parsed in
this mode but with some restrictions - e.g. functions have to be
defined before called.

Забележка:
Autoloading is not available if using PHP in CLI
interactive mode.

-c

--php-ini

This option can either specify a directory where to look for
php.ini or specify a custom INI file
(which does not need to be named php.ini), e.g.:

Activate the extended information mode, to be used by a
debugger/profiler.

-f

--file

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

Забележка:
To pass arguments to scripts the first argument needs to be
--, otherwise PHP will interperate them as PHP
options.

-h and -?

--help and --usage

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

-i

--info

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 when using the CGI mode the output is in HTML
and therefore quite huge.

-l

--syntax-check

This option provides a convenient way to only perform a syntax check
on the given PHP code. On success, 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 -1.

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

Забележка:
This option does not work together with the -r
option.

-m

--modules

Using this option, PHP prints out the built in (and loaded) PHP and
Zend modules:

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.

If you are using a shell different from sh/bash, you might experience
further issues. Feel free to open a bug report at
» http://bugs.php.net/.
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.

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.

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/ld.so.conf 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.

--ini

Shows configuration file names and scanned directories. Available as
of PHP 5.2.3.

Shows the configuration information for the given extension (the same
information that is returned by phpinfo()).
Available as of PHP 5.2.2. The core configuration information
are available using "main" as extension name.

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.

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

<?php} 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 #9 Batch file to run a command line PHP script (script.bat)

@echo OFF
"C:\php\php.exe" script.php %*

Assuming you named the above program
script.php, and you have your
CLI php.exe in
C:\php\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.

User Contributed Notes 69 notes

You can easily parse command line arguments into the $_GET variable by using the parse_str() function.

<?php

parse_str(implode('&', array_slice($argv, 1)), $_GET);

?>

It behaves exactly like you'd expect with cgi-php.

$ php -f somefile.php a=1 b[]=2 b[]=3

This will set $_GET['a'] to '1' and $_GET['b'] to array('2', '3').

Even better, instead of putting that line in every file, take advantage of PHP's auto_prepend_file directive. Put that line in its own file and set the auto_prepend_file directive in your cli-specific php.ini like so:

auto_prepend_file = "/etc/php/cli-php5.3/local.prepend.php"

It will be automatically prepended to any PHP file run from the command line.

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!

Assuming --prefix=/usr/local/php, it's better to create a symlink from /usr/bin/php or /usr/local/bin/php to target /usr/local/php/bin/php so that it's both in your path and automatically correct every time you rebuild. If you forgot to do that copy of the binary after a rebuild, you can do all kinds of wild goose chasing when things break.

If your php script doesn't run with shebang (#!/usr/bin/php),and it issues the beautifull and informative error message:"Command not found." just dos2unix yourscript.phpet voila.

If you still get the "Command not found." Just try to run it as ./myscript.php , with the "./"if it works - it means your current directory is not in the executable search path.

If your php script doesn't run with shebang (#/usr/bin/php),and it issues the beautifull and informative message:"Invalid null command." it's probably because the "!" is missing in the the shebang line (like what's above) or something else in that area.

This posting is not a php-only problem, but hopefully will save someone a few hours of headaches. Running on MacOS (although this could happen on any *nix I suppose), I was unable to get the script to execute without specifically envoking php from the command line:

[macg4:valencia/jobs] tim% test.php./test.php: Command not found.

However, it worked just fine when php was envoked on the command line:

And you did, of course, remember to add the php command as the first line of your script, yeah? Of course.

#!/usr/bin/php<?php print "Well, here we are... Now what?\n"; ?>

So why dudn't it work? Well, like I said... on a Mac.... but I also occasionally edit the files on my Windows portable (i.e. when I'm travelling and don't have my trusty Mac available)... Using, say, WordPad on Windows... and BBEdit on the Mac...

Aaahhh... in BBEdit check how the file is being saved! Mac? Unix? or Dos? Bingo. It had been saved as Dos format. Change it to Unix:

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.

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.

If you are using Windows XP (I think this works on 2000, too) and you want to be able to right-click a .php file and run it from the command line, follow these steps:

1. Run regedit.exe and *back up the registry.*2. Open HKEY_CLASSES_ROOT and find the ".php" key.

IF IT EXISTS:------------------3. Look at the "(Default)" value inside it and find the key in HKEY_CLASSES_ROOT with that name.4. Open the "shell" key inside that key. Skip to 8.

IF IT DOESN'T:------------------5. Add a ".php" key and set the "(Default)" value inside it to something like "phpscriptfile".6. Create another key in HKEY_CLASSES_ROOT called "phpscriptfile" or whatever you chose.7. Create a key inside that one called "shell".

8. Create a key inside that one called "run".9. Set the "(Default)" value inside "run" to whatever you want the menu option to be (e.g. "Run").10. Create a key inside "run" called "command".11. Set the "(Default)" value inside "command" to:

cmd.exe /k C:\php\php.exe "%1"

Make sure the path to PHP is appropriate for your installation. Why not just run it with php.exe directly? Because you (presumably) want the console window to remain open after the script ends.

You don't need to set up a webserver for this to work. I downloaded PHP just so I could run scripts on my computer. Hope this is useful!

i use emacs in c-mode for editing. in 4.3, starting a cli script like so:

#!/usr/bin/php -q /* -*- c -*- */<?php

told emacs to drop into c-mode automatically when i loaded the file for editing. the '-q' flag didn't actually do anything (in the older cgi versions, it suppressed html output when the script was run) but it caused the commented mode line to be ignored by php.

in 5.2, '-q' has apparently been deprecated. replace it with '--' to achieve the 4.3 invocation-with-emacs-mode-line behavior:

#!/usr/bin/php -- /* -*- c -*- */<?php

don't go back to your 4.3 system and replace '-q' with '--'; it seems to cause php to hang waiting on STDIN...

// Create the handles for our two pipes (two handles per pipe, one for each end)// We will have one pipe for stdin, and one for stdout, each with a READ and WRITE endHANDLE hStdoutRd, hStdoutWr, hStdinRd, hStdinWr;

Or you may encounter some other strange problem.Care the enter key. In windows environment, enter key generate two binary characters '0D0A'. But in Linux, enter key generate just only a 'OA'.I wish it can help someone if you are using windows to code php and run it as a command line program on linux.

One of the things I like about perl and vbscripts, is the fact that I can name a file e.g. 'test.pl' and just have to type 'test, without the .pl extension' on the windows command line and the command processor knows that it is a perl file and executes it using the perl command interpreter.

I did the same with the file extension .php3 (I will use php3 exclusivelly for command line php scripts, I'm doing this because my text editor VIM 6.3 already has the correct syntax highlighting for .php3 files ).

dunno if this is on linux the same but on windows evertimeyou send somthing to the console screen php is waiting forthe console to return. therefor if you send a lot of small short amounts of text, the console is starting to be using more cpu-cycles then php and thus slowing the script.

on the screen just appears "abcde". but if you write your script this way it will be far more faster:cpu-cycle:1 ->php: ob_start();cpu-cycle:2 ->php: print("abc");cpu-cycle:3 ->php: print("de");cpu-cycle:4 ->php: $data = ob_get_contents();cpu-cycle:5 ->php: ob_end_clean();cpu-cycle:6 ->php: print($data);cpu-cycle:7 ->cmd: output("abcde");

now this is just a small example but if you are writing anapp that is outputting a lot to the console, i.e. a textbased screen with frequent updates, then its much better to first cach all output, and output is as one big chunk oftext instead of one char a the time.

ouput buffering is ideal for this. in my script i outputtedalmost 4000chars of info and just by caching it first, itspeeded up by almost 400% and dropped cpu-usage.

because what is being displayed doesn't matter, be it 2chars or 40.0000 chars, just the call to output takes a great deal of time. remeber that.

maybe someone can test if this is the same on unix-basedsystems. it seems that the STDOUT stream just waits for the console to report ready, before continueing execution.

In a bid to save time out of lives when calling up php from the Command Line on Mac OS X.

I just wasted hours on this. Having written a routine which used the MCRYPT library, and tested it via a browser, I then set up a crontab to run the script from the command line every hour (to do automated backups from mysql using mysqldump, encrypt them using mcrypt, then email them and ftp them off to remote locations).

Everything worked fine from the browser, but failed every time from the cron task with "Call to undefined function: mcrypt [whatever]".

Only after much searching do I realise that the CGI and CLI versions are differently compiled, and have different modules attached (I'm using the entropy.ch install for Mac OS-X, php v4.3.2 and mysql v4.0.18).

I still can not find a way to resolve the problem, so I have decided instead to remove the script from the SSL side of the server, and run it using a crontab with CURL to localhost or 127.0.0.1 in order that it will run through Apache's php module.

Just thought this might help some other people tearing their hair out. If anyone knows a quick fix to add the mcrypt module onto the CLI php without any tricky re-installing, it'd be really helpful.

Example 43-2 shows how to create a DOS batch file to run a PHP script form the command line using:

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

Here is an updated version of the DOS batch file:

@c:\php\cli\php.exe %~n0.php %*

This will run a PHP file (i.e. script.php) with the same base file name (i.e. script) as the DOS batch file (i.e. script.bat) and pass all parameters (not just the first four as in example 43-2) from the DOS batch file to the PHP file.

This way all you have to do is copy/rename the DOS batch file to match the name of your PHP script file without ever having to actually modify the contents of the DOS batch file to match the file name of the PHP script.

This took me all day to figure out, so I hope posting it here saves someone some time:Your PHP-CLI may have a different php.ini than your apache-php. For example: On my Debian-based system, I discovered I have /etc/php4/apache/php.ini and /etc/php4/cli/php.iniIf you want MySQL support in the CLI, make sure the line extension=mysql.sois not commented out.The differences in php.ini files may also be why some scripts will work when called through a web browser, but will not work when called via the command line.

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

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:chdir(preg_replace('/\\/[^\\/]+$/',"",$PHP_SELF));

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

Under Solaris (at least 2.6) I have some problems with reading stdin. Original pbms report may be found here: http://groups.google.com/groups?q=Re:+%5BPHP%5D+Q+on+php://stdin+--+an+answer!&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3C74AF57.6090704%40Sun.COM&rnum=1

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:1->foo\nboo\ndoo2->goosince double quotation mark has a special meaning and get stripped off of the input stream.Indeed, according to PHP manual:[quote]array fgetcsv ( int fp, int length [, string delimiter [, string enclosure]])

[skip]another delimiter with the optional third parameter. _The_enclosure_character_is_double_quote_,_unless_it_is_specified_.[skip]_enclosure_is_added_from_PHP 4.3.0. !!!!!![/quote]

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 !!!$s=file("php://stdin");for ($i=0,$n=sizeof($s);$i<$n;$i++){ do_something_useful(rtrim($s[$i]));}

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

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

Good luck!Dim

PS. Don't forget that it's only Solaris specific problem. Under Linux just use usual fgets()...

To pass more than 9 arguments to your php-script on Windows, you can use the 'shift'-command in a batch file. After using 'shift', %1 becomes %0, %2 becomes %1 and so on - so you can fetch argument 10 etc.

I had problems running php as CGI in thttpd. I have followed instructions posted by db at digitalmediacreation dot ch, but I was still getting "500 Internal Error" answer from the server. However, I had no problems running php as CLI using a simple wrapper file named index.cgi:

#!/usr/bin/php<?phprequire_once 'index.php';?>

but i needed to pass user data through GET and POST, and this method couldn't handle it. I have spent 2 hours figuring out how to run the CGI mode properly, until I finally gave up, and done it in "manual" way. I have just added some code to the wrapper that reads GET and POST data into the proper variables:

#!/usr/bin/php<?php

//parse the command line into the $_GET variableparse_str($_SERVER['QUERY_STRING'], $_GET);

Using CLI (on WIN at least), some INI paths are relative to the current working directory. For example, if your error_log = "php_errors.log", then php_errors.log will be created (or appended to if already exists) in whatever directory you happen to be in at the moment if you have write access there. Instead of having random error logs all over the place because of this behavior, you may want to set error_log to a full path, perhaps to the php.exe directory.

I've just found that the fact that the CLI does *not* change the current directory will make include() and require() calls with relative paths fail. This is because they are relative to the current directory, not to the current executing file, the documentation notwithstanding. In CGI mode, this is the same because it changes the current directory.

One solution is to call the CGI binary rather than the CLI one. A better solutions is to use dirname(__FILE__) in your path names.

Here's an update to the script a couple of people gave below to read arguments from $argv of the form --name=VALUE and -flag. Changes include:

Don't use $_ARG - $_ is generally considered reserved for the engine.
Don't use regex where a string operation will do just as nicely
Don't overwrite --name=VALUE with -flag when 'name' and 'flag' are the same thing
Allow for VALUE that has an equals sign in it

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:

I append this to most of my PHP files, to allow command line unit testing of a class. It ensures that the unit test is only run if the script is run directly, and won't be triggered by an include from another CLI script.

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.

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 typesFind 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.