CHAPTER 16 – The Shell-Scripting Environment
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.