PHP is a powerful scripting language but did you know it can be used from the command-line as well? Using PHP from the CLI has many applications from checking what version of PHP is installed to being able to execute scripts and even check the syntax of a file. If you’ve never used PHP from the command-line, I recommend pulling up a terminal (I recommend iTerm2) and follow along with some common use cases.

php –help

Use this for a full list of options and arguments (worth a peek as I won’t be discussing all of the arguments in this post)

php -v

Displays the version number and copyright information for PHP as well as some of the modules you may have loaded. Here’s an example from my system:

PHP 5.3.16 with Suhosin-Patch (cli) (built: Oct  2 2012 21:29:21)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
	with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

Please note that it is possible for the command-line version of PHP to be different from the version being used by the web server. In those scenarios it’s better to use phpinfo() to get the version number that the web server is running.

php -i

This flag is the command-line equivalent of phpinfo() and is actually readable from the CLI as it’s not full of markup.

php -f <file>

Specifying a file will execute the file from the command-line. The -f can be omitted and additional command-line arguments can be passed to the script by listing them after the file name:

php -f /path/to/file.php arg1 arg2 arg2

The additional arguments will be available in the argument count and vector variables. $argc contains the number of arguments and $argv is an array of the arguments in order. Keep in mind that the name of the file will also be present as it is considered the first argument being passed in. When dumping the variables from the example above (just use var_dump($argc, $argv)) the resulting data dump will be:

int(4)
array(4) {
  [0] => string(17) "/path/to/file.php"
  [1] => string(4) "arg1"
  [2] => string(4) "arg2"
  [3] => string(4) "arg3"
}

php -r <code> and php -a

In addition to executing the code in a file, you can execute it directly from the command-line itself. You don’t need to include the PHP delimiters &lt;?php and ?&gt; but you will need to wrap the code snippet in quotes else it will be evaluated incorrectly and won’t run.

An alternate approach to this would be running PHP’s interactive shell mode (-a) which gives you a dedicated PHP shell to hack on. The advantage to using the interactive shell would be that you can easily do multi line editing and no worrying about wrapping the commands in quotes (which I personally find a pain to remember).

php -s <file> and php -w <file>

These are two options that I’ve never used but I can see the value in them. -s outputs the syntax highlighted markup (the equivalent of the PHP functions highlight_file() and highlight_source()). This could be useful for generating documentation from the source code or if you need the prettified output for a website or perhaps even a presentation of some sort.

The other option, -w does the opposite. Instead of making the file pretty, it strips the file’s whitespace and the comments. I’m not generally a fan of source code that lacks comments and is not well-formatted but I suppose if you’re attempting to obscure the source code a bit this would help. Obviously there are better ways to obscure the code so perhaps the other application would be saving space on a server by reducing the file sizes or even speeding up execution by having no comments and less whitespace to parse through.

php -l <file>

Quite possibly the most invaluable command-line functionality with PHP is the ability to lint a file. If you’re not familiar with the term, let me explain. When you lint a file, you’re checking that the syntax is correct and that the code will actually be able to run. Having this functionality at your finger tips is excellent but I do recommend that you find a more automated workflow to help limit issues. This can be done automatically by your editor, at the very least when you save files or even set up as part of a version control system’s hook to ensure you’re not committing scripts with errors.

php –not-covered

As mentioned, I didn’t cover all of the command-line arguments and options so feel free to explore the --help documentation. What I did cover were the things that I use most commonly as well as a few other arguments I felt were interesting and noteworthy.