Chance Garcia has a recent post to his blog showing how he fixed an issue with his MAMP install involving development of a SSH wrapper he developed and some testing out of PHPStorm and PHPUnit.

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.

Continuing on with his previous investigations into microframworks and what it takes to create them, Gonzalo Ayuso has posted his second part of the series - a look at working on the command line.

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.

In a new post to his blog Stuart Herbert has introduced phix, a packaging tools that can be used to manage and install different components in a framework-agnostic sort of way.

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.

Simas Toleikis has a new post today looking at a method he's found for creating a simple daemon application in PHP. He gives you the basic outline of how it works (with a bit of code included) but not a specific example.

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.

New on PHPBuilder.com today there's a tutorial from Jason Gilmore about running Zend Framework-based applications from the command line in a more hard-coded way than using Zend_Tool.

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.

Brian Moon has a quick post that links to a but of code that gives you a progress bar for the command line that's flexible enough to be used in an number of situations.

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.

Davey Shafik has a quick tip for anyone trying to use Xdebug from the command line and finding themselves having issues.

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.

In the second part of his series looking at asynchronous processing in PHP applications, Padraic Brady lays the ground work for the third part and shows how to work with command line Zend Framework applications.

Part 2 is a tangential detour into how to make a Zend Framework based application accessible from the command line before we delve into examples using this in future parts of the series. If you are not a Zend Framework user, I'm sure you can find relevant material online for your own preferred framework though the ZF pieces may still have some usefulness in understanding the approach from an MVC perspective.

In his examples he skips over the basics of using a command line application and jumps right to things like argument handling, creating a custom router and making a custom "calling script" to handle the configuration of the CLI application.

Paul Jones has a quick hit reminder of some of the recent blog entries around the web about using the Solar framework:

• Solar CLI: Make-model - a look at the auto-generation feature of the Solar command-line tool to create model classes based on your database tables.
• A more in-depth look at the solar configuration file
• And, for those new to the framework, a Getting Started guide.

You can find out more about the Solar framework on the project's website including documentation, a current bugs list and a link to the community wiki.

Johan Mares has a recent post about using PHP on the command line:

I already knew how to run PHP scripts from the command line (CLI), although I never really used it. What was new to me was that there are 2 ways of doing this. The first one is by using the php command and the second, and new for me, is by adding a shebang on the first line of your script.

His first way is to run the PHP file through the interpreter directly (via a command line call to something like "php myfile.php"). The second it to actually include the path to the interpreter inside the PHP file itself and use the shell to execute the contents based on that (adding something like "#!/path/to/php" at the top). Then you just make the file executable and you can run it like any other binary file.