Good tools are invaluable in figuring out where problems lie, and can also help to prevent problems from occurring in the first place, or just help you to be more efficient in general. Command line tools are particularly useful because they lend themselves well to automation and scripting, where they can be combined and reused in all sorts of different ways. Here we cover six particularly powerful and versatile tools which can help make your life a little bit easier.

The tools they mention are all things you'd install on a unix-based system:

• Curl
• Ngrep (network packet searching)
• Netcat (to work with network connections)
• Sshuttle (SSH tunneling)
• Siege (HTTP benchmarking)
• Mitmproxy (capturing proxy, both HTTP and HTTPS)

Rasmus mentioned on IRC how he ran the [command line] tests: simply renaming the ".phpt" test files as ".php", and invoking them through the CLI webserver. The SKIPIF sections get executed, but that doesn't affect the desired outcome of testing multiple HTTP requests with different input scripts. [Here] are some quick shell scripts I put together to automate testing the OCI8 extension with valgrind.

He uses the OCI8 extension as an example, showing how to set up these scripts to enable the execution of the tests, fire up the web server and execute Valgrind to help monitor the memory of the execution.

Over the weekend, I was toying with the idea of interactive cli applications using readline() and Zend Form for validating input. My motivation for using Zend Form or rather Zend Form elements was to exploit the power of features such as labels, validators, filters and the prospect of reusing forms within web application code.

His example code defines a Filter for the form errors (returning them as a string) and a "Cli" class that handles the interaction with the command line. Next up is a class defining the form elements - a prompt for a color name and either of the words "thank" and "you". The Cli class transforms the form elements into prompts on the command line and lets you define validators to check their input.

One thing I can say is that, even though I use a convenient app like MAMP PRO to set up my local development environment, I'm glad my sysadmin-fu is up to snuff enough to fly without the conveniences because after this ordeal, I feel like I might as well have made my MAMP stack from scratch with all the hoops I jumped tonight.

He shares a few of the things he discovered along the way like: the location of MAMP's "pecl" command, an error caused by a bad pear.conf file, doing custom compiles of PHP and libssh as a fallback and getting the extension to work in the CLI PHP version too.

In my last post we spoke about building a small microframework with PHP. The main goal of this kind of framework was to be able to map urls to plain PHP classes and become those classes easily testeable with PHPUnit. Now we're going to take a step forward. [...] It's pretty straightforward to create a command line interface (CLI) for our microframework.

He shows how to use the getopt function and the $GLOBALS superglobal to pull in arguments given to the command line script. He hooks this into the framework and makes it possible to define the controller and action to execute (with a few examples to show it in action). You can find this updated code on his github account.

phix is a small command-line tool for PHP applications. I created it to fix (pun intended) the problem of how to easily automate the tasks involved in creating and (especially) maintaining components. These tasks aren't built into phix; they are commands that ship with the phix distribution. You can create your own commands to run inside phix too, and it's easy to do so

The phix tool (easily installed from PEAR) lets you either use built-in commands or custom ones to manage libraries with a few different kinds of commands - current status, initialize a library, upgrade a library and manage the full web application. As of the time of this post, the current version is phix-0.10.4.

There is a special group of applications that require a different PHP script execution model. [...] All of [these special] applications need to be run in the background as daemons - something that PHP was never designed/supposed to be good at. The plain C language is a weapon of choice when it comes to writing a daemon implementation, but then again, if the application in question does not depend on high performance and concurrency - PHP can do the job quite well.

He talks about using the command line interface to run the scripts, creating the while loop to keep execution going and creating the non-blocking socket so that the script can accept new client connections. He also mentions using upstart to run the script in the background and the proctitle PECL extension to give the process a custom name in the process list. He also touches on log files and forking/parallel processing.

I regularly use an alternative application of PHP and I'm quite surprised that this capability remains relatively unknown. I'm referring to the ability to run PHP scripts from the command line using its command line interpreter (CLI). Even though it's been possible since the PHP 4.3.0 release, you may be completely unaware of this CLI usage unless you employ great tools such as PHPDoc, Phing, or PHPUnit. Running PHP scripts with CLI allows you to leverage your PHP language skills whenever you need to run scripts from the shell.

He talks about what the CLI functionality of PHP is and what it has to offer the developer. He then creates a few sample scripts so you can get a feel for how to write and run simple PHP CLI applications. Building on these examples, he creates a Zend Framework-based script that loads in the bootstrap, grabs configuration values and makes a connection to the Amazon Web Services.

Was just looking through some code and came across this function I wrote some time ago. If you do a lot of your processing scripts in PHP like we do, you probably need to know what is going on sometimes. So, I made a progress bar for use on the cli. I thought I would share it.

You can see a demo of it here (screencast) or just download the code. Comments on the post also point out the PEAR Console_Progressbar package and the ez Components class for creating a more advanced progress bar.

Thanks to some help from Derick and my co-worker Trevor, I now have a simple bash script that will let me and my team easily debug CLI scripts on our development server.

The script is two lines (really just one) that uses a combination of environment variables, PHP's command line binary and a few other standard unix commands to parse the output of the request. The script can be made executable and dropped into a place in your path to make it as simple as running "xdebug file.php" on the file.