The CLI PHP script operates differently in its environment compared to its
web-server embedded counterpart. Shell scripts are running in their own pro-
cess, containing PHP and nothing else. Inside a web server, PHP shares the
process with the web server itself and any other modules the web server may
have loaded. The web server environment has many restrictions because of
this. For example, who gets standard input? What about signals, and what
happens if you fork (duplicate) the process? Usually all of these types of
resources are managed by the hosting web server.

User Input
If you need user input in a PHP shell script, you should
use standard input, which is available in the PHP stream STDIN or the “termi-
nal typewriter” device on UNIX flavors /dev/tty.
<?php
print “What is your one purpose in life? “;
$purpose = trim(fgets(STDIN));
?>
If you are writing a script that needs to read from standard input as well
as read user input from the terminal, you must use /dev/tty for user interac-
tion. On Windows, you can’t read from STDIN at the same time as when you
reading from the terminal.

Execution Lifetime
When embedded in a web server, PHP scripts
usually do their job quickly and exit. This paradigm does not fit when using
CLI; your scripts may run forever, or at least until the next power failure. For
example, if you write a daemon (UNIX lingo for a server process running in
the background), the script will typically hang around forever, waiting for
some kind of input to process, a timer signal, or something similar.
One of the practical consequences of this is that sloppy coding styles,
which are relatively harmless in a short web-server request, have more of an
impact in a long-running script. For example, when you open a file or database
connection but don’t explicitly close it, PHP closes it for you at the end of the
request. But in a long-running script, “at the end of the request” is not until
the script exits, which it does not even have to do.
This does not have to be a problem, because PHP also frees resources
when they are no longer referenced. But keep this in mind when programming
scripts that are supposed to run for some time. If you are finished with a file,
close the file descriptor. If you’re finished with database operations, discon-
nect. If you don’t need that big array anymore, empty it.

Hash-Bang Whiz-Blam
On UNIX-like systems, if the first two char-
acters of an executable file are “#!” (called hash-bang), the rest of the line is
treated as the name of the program executing the file. The specified program is
invoked with the script’s name as the first parameter, followed by the parame-
ters given to the script itself.
Let’s say you make a PHP script called “myreport,” which starts like this:
#!/usr/bin/php -Cq
<?php
require_once “DB.php”;
$db = DB::connect(”mysql://….
First, ensure that the script is executable, like this:
$ chmod +x myreport
Then, when you run myreport traffic, your shell first searches for myre-
port in the directories listed in its PATH environment variable–say it is located
in the /usr/local/bin directory.
When the shell finds it there, it tells the operating system to execute this
program. The OS then opens the file, discovers the #! characters, and re-
executes the process as
/usr/bin/php -Cq /usr/local/bin/myreport traffic.
When PHP finally starts, it imports ./myreport and traffic into the $argv
array, and then executes your script.
Note that because the shell searched your PATH to find the actual location
of myreport, which the OS then used when executing PHP, $argv[0] will con-
tain the full path to myreport. If you had specified a relative path, such as ../
bin/myreport, the shell would not have searched PATH and $argv[0] would also
become ../bin/myreport.