These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

There are a few commercial products out there that allow you to turn your php scripts into an executable. While most of them work well, I have found a way to do it for free, using an open source application. This application is called Wapache (based on the apache web server) and it is open source (distributed under the Apache License 2.0). WApache doesn't convert your script directly into an executable, it runs on the combination of a windows app (which uses an embedded IE control) and a stripped down version of apache.

The tool acts as a wrapper around the script, making it look and feel like a normal executable Windows file. Your PHP scripts stay intact and can be changed at any time without needing to recompile or anything. There's also some configuration options included that let you customize the interface.

There are a few commercial products out there that allow you to turn your php scripts into an executable. While most of them work well, I have found a way to do it for free, using an open source application. This application is called Wapache (based on the apache web server) and it is open source (distributed under the Apache License 2.0).

WApache does the trick by combining your script with stripped down versions of an IE browser and an Apache web server. This is compiled together and pushed out the other end as an executable file. Instructions are included in the post to get you started making the .exe files quickly.

The Zend Executable Debugger plug-in is part of the all-in-one PDT package, but if you want to install it on your own'"since it's possible to use this debugger without the PDT and with PHPEclipse, for example'"then you'll need to install it using the Eclipse Update Manager (the easier way).

He mentions how to install the tool (including the information for the Update Manager) and attaches some screenshots of the tool in action - first of the installer and second of the plugin in action.

UPDATE: Ben added a note about XDebug support for the PDT software into the post as well:

Patrick Mueller has just posted some links to information about XDebug support for PDT. Now, for those not wishing to use the Zend Debugger, you may now use XDebug.

You can find out more about this free tool from their website or just download a copy and start checking it out.