PHP

Free PHP book resources & Tutorials

CHAPTER 16 - Parsing Command-Line Options - Examples

Here are some examples of command-line tools written in PHP.
PHP Filter Utility
This example includes a little tool for filtering line
by line from standard input through a PHP function that returns a string:

CHAPTER 16 - Parsing Command-Line Options - Signals

In UNIX, signals are a basic mechanism to pass messages
between processes. They enable processes to tell each other that some type of
event has just occurred. This type of event is the only information passed to
basic UNIX signal handlers. There is another signal-handling mechanism
called “sigaction” in which signal handlers receive more information, but PHP
signals are based [...]

CHAPTER 16 - Parsing Command-Line Options - Exec

When one program runs another program, the execution of
the second program is actually a two-step procedure. First, the calling process
forks and makes a duplicate of itself, and then immediately does an exec call
to replace the executable code and memory with that of the new program.
If you just want to run a program and read the [...]

CHAPTER 16 - Parsing Command-Line Options - Forking

Forking is UNIX lingo for making a new process by dupli-
cating an existing one. The duplicate (child) process inherits code, environ-
ment, memory (copy on write), file descriptors, and everything from the parent
process. Often, you either immediately replace the guts of the process by exe-
cuting another executable program, or close inherited file descriptors and pre-
pare the [...]

CHAPTER 16 - Parsing Command-Line Options 2

Exit Code
If the script fails, exit with a non-0 code (except 255,
which is reserved by PHP itself for compile/parse errors). If the script does not
fail, exit with code 0.
Be aware that earlier PHP versions (pre-4.2) had a bug in the exit code
handling. Exiting in any other way than letting the script finish results in a
“non-true” [...]

CHAPTER 16 - Parsing Command-Line Options

Command-line options are used in UNIX to specify alternate behavior or addi-
tional parameters for commands. You spot them by the leading dash. Here are
some examples:
$ ls ­ltr
$ rm ­f junk
Usually, options are located before regular parameters (that do not start
with a dash) on the command line. Some commands, such as cvs or pear, have
additional subcommands [...]

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 [...]

CHAPTER 16 - php.ini Name and Location

On UNIX-like systems, PHP (with
back-ends other than CLI) looks for php.ini in /usr/local/lib by default. To be
more “shell-ish,” the CLI back-end looks for /etc/php-cli.ini by default, instead.
This makes it possible to keep separate php.ini files for your web server and
CLI/shell scripts, without having to specify the ­c option every time you run a
PHP-driven script.
[...]

CHAPTER 16 - How CLI Differs From CGI

The CLI version of PHP is quite similar to the CGI version, upon which it was
once based. The main difference lies in all the web server integration, which is
really what CGI is about. With CLI, PHP is trimmed down to the very basics,
and imports no GET or POST form variables, outputs no MIME headers in [...]

CHAPTER 16 - PHP CLI SHELL SCRIPTS

The CLI version of PHP is meant for writing standalone shell-scripts running
independently from any web server. As of PHP 4.3.0, the CLI version of PHP
is installed by default, alongside whatever web server interface you choose to
install.

CHAPTER 16 - PHP Shell Scripting

Traditionally, PHP is used in web environments to produce HTML markup
that the user views in a web browser. The interaction between PHP and the
web server (Apache, AOLserver, Microsoft IIS, or whatever) happens through
a layer called SAPI (short for web Server API). A separate build of PHP is
required to interface with each type of web server [...]

CHAPTER 15 - Thread-Safe Resource Manager Macros

By now, you must have noticed the use of macros here and there starting with
TSRM, which stands for Thread-Safe Resource Manager. These macros give
your extension the possibility of having its own global variables, as previously
mentioned.

CHAPTER 15 - Adding Custom INI Directives

The INI file (php.ini) implementation allows PHP extensions to register and
listen to their own custom INI entries. If these INI entries are assigned a
value either by php.ini, Apache’s .htaccess, or other configuration methods,
the registered INI variable will always be updated with the correct value. This
whole INI framework has many different options and allows for a [...]

CHAPTER 15 - Global Variables

You might want to use global C variables in your extension, either for your
own internal use or for receiving php.ini values of your extension’s registered
INI directives (INI is discussed in the next section). As PHP is designed to run
in multi-threaded environments, you shouldn’t define global variables on your
own. PHP supplies a mechanism that creates global [...]

CHAPTER 15 - Testing the Extension

You are now ready to write a test script to
check that the extension works. Here’s a sample script that opens a file
test.txt, prints its contents to the standard output, and creates a copy of the
file as test.txt.new:

CHAPTER 15 - Macros Used to Access zval Values

All macros have three forms:
one that accepts zvals, another one for zval *s, and finally one for zval **s.
The difference in their names is that the first has no suffix, the zval * has a
suffix of _P (as in one pointer), and the latter, zval **, has a suffix of _PP (two
pointers).
[...]