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.
Chuck Burgess has posted a discovery he made while working with Eclipse PDT and a command line script that he needed to debug:
This week, I found a need to do this same kind of remote debugging, but for a command-line PHP script. This seems to be something that Eclipse is not already designed to do, as there is no "perpetual listener" available for its debug client. Instructions for remote CLI debugging are available, which showed me that environment variables might be the missing link to getting it working with Eclipse. It turned out to be one of two missing links. The other link was tricking Eclipse into keeping a debug session open (and therefore "listening").
He found that by loading up the PHP file in a shell script with the XDEBUG_CONFIG and XDEBUG_SESSION variables defined, it allows the Eclipse listener to connect and work through the file like a normal web page request.
A new post to the Solar blog takes a look at a set of included tools the framework offers for working with command-line applications.
One of the nice things Solar has to offer is its CLI (Command Line Interface), which can be used to accomplish tasks that would otherwise eat up valuable time, such as creating a new project, applications, models, tests, and documentation. In this entry, and others that will follow, I will be showing you how to use the current (Solar v1.0.0 alpha2) CLI, detailing commands, available options, parameters, and usage examples.
This entry is the first in a series on the subject and gives just the basics of the cli component - where to find it, how get help with its functionality (a "help" command) and some resources to get more information.
Chris Hartjes has a new post to his blog today focusing on using a bit of the CakePHP framework's functionality from the command line.
I'm porting a spaghetti-PHP application over to using CakePHP I am moving their existing authorization system over to using Cake's Auth component. Of course, they are storing all their passwords in plaintext in the user account table, so I needed an easy way to convert all the existing passwords over to be encrypted using the same hash that Auth would use.
With the help of the shells and tasks that the framework makes availiable, he's able to make a simple 24 line class (EncryptPasswordShell) that extends the Shell object and loops through the data to push it back into the database in the correct password format.
In a new post to his blog, Paul Jones anout a small issue when working with the PHP 5.2.5 command line functionality - a segfault if you extend the Exception class.
When executing code at the command line using php -r and PHP 5.2.5, be sure not to extend the Exception class. It will cause a segmentation fault.
He includes examples of the issue that would cause the problem and the bug he's filed in an effort to get it fixed.
Amir Saiedrecently posted a handy little tool for the PEAR users out there - a bash script that handles tab completion for you.
Lately I've been playing alot with the PEAR CLI. The one annoying thing I noticed the most was its lack of tab completion that I'm used to from the shell. It turns out that this feature is very easy to add, in the bash at least.
It will finish off the PEAR commands for you and expand out the PEAR package names and discovered channels when it finds a match. You can download the package here.
template_engine - a simple templating engine (and the example package for namespace usage)
Not really what I expected to be the first round of new code, but its nice to be setting up access for people. Oh and remember PEAR2 is targeted at php 5.3 but not everything is namespaced yet since not everyone wants to run snapshots of php for development.
On the Developer Tutorials blog, Akash Mehta has posted an introduction to working with command-line PHP scripts and cron jobs for site automation.
Scheduled tasks are a fairly common feature in modern web applications. From cleaning out caches every 24 hours to checking subscription periods and even generating reports, more web applications live by the clock than ever before. But how do we schedule the execution of a PHP script on the server side?
He shows the two key things to getting it working - an example of a command-line call to a PHP script (executed through his /usr/bin/php) and an example of a line from a crontab showing how to execute the script at midnight every day.
Akash Mehta shares a helpful hint in this new post to the Developer Tutorials Blog today - testing out PHP code via the command line PHP binary.
Thankfully, PHP provides the interactive shell, allowing you to test out PHP interactively with immediate feedback. Here's how to take advantage of this mature feature of PHP.
With the help of the "-a" flag on the command line, the PHP binary will hand you an environment where you can code PHP and instantly see the results. He does mention a few quirks that make it different than working with PHP through a web server, namely moving in and out of code blocks and remembering to finish out with a semi-colon when the line is done.
New on the Debuggable blog today there's this post from Tim Koschutzki about a new feature he's contributed back to the CakePHP project. It allows you to run tests on the command line without having to worry about loading up a web interface to check your code.
It allows you to run all of the following: all core testcases at once, all core test groups, each core test case individually, all application-specific testcases at once, all application-specific test groups and each core test case individually. It also supports plugins, which means you can run plugin cases and groups.
He includes some samples of how it works - a few command line calls and what the output looks like.
