Colin O'Dell has shared an interesting setup he's created to make it easier to switch between PHP versions when testing your code. In his latest post he shows how to switch the version "on cd" (directory change) with the help of some command line shell tooling.

After using phpbrew to manage my local PHP versions for a while, I got tired of re-compiling PHP after every release and decided to install multiple PHP versions side-by-side with Ond?ej Surý's PPA. One of the features I missed from phpbrew was the ability to run a command like phpbrew use php-7.2.8 to automatically change the php command to that version, so I ended up implementing this feature myself using symlinks and shell aliases.

He then walks through his end result, showing the modification of the default php symlink and aliases that can be used to dynamically switch its target. He then includes some examples of how to automate this using your application's PHP version requirements in the composer.json and a simple ZSH script that's triggered on directory change.

On the Laravel News site today there's a post introducing you to Tinker the command-line REPL (read-eval-print-loop) tool that integrates with the Laravel artisan command-line tool.

Laravel includes a powerful REPL, called Tinker, powered by the PsySH console by Justin Hileman under the hood. The tinker console allows you to interact with your Laravel application from the command line in an interactive shell.

Tinker used to be part of the laravel/framework package, but with the release of Laravel 5.4 is extracted into separate package.

They start the post by talking about what a REPL is and how it can be used to test things on the command line without needing to write up a full test script. They then show how to install the tool Tinker is based on globally (Psych) including a brief overview of how to use it. Next comes the Tinker-specific functionality including examples of the documentation commands, testing helpers and job execution features.

Rob Aley pointed me towards a new ebook he's created that wants to help you understand what kinds of things PHP can do "beyond the web" and the usual web-based applications - PHP Beyond the Web.

Leverage your existing web based PHP skills to write all types of software. CLI scripts, desktop software, network servers and more - this book will give you the tools, techniques and background necessary to write just about any type of software you can think of, using the PHP you know.

The book covers topics like interactive shell scripts, system daemons and desktop software. It also looks at some more general development topics like licensing, deployment and system interactions. If this sounds interesting and you want a sample of the content, check out the table of contents or the sample chapter.

There's a feature that's usage has been showing up more and more in software projects (both open source and not) that allows you to install their system with a single line command, usually involving curl and maybe piping it to a shell. In this recent post Michael Maclean takes a look at this trend and some of the possible pitfalls of the approach.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

Chris Jones has a new post today showing how you can use PHP 5.4's built-in web server to help test for memory issues in your application (and the language).

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.

DevShed.com has a new tutorial posted today looking at how to sanitize data in your application, specifically data coming from the user, when calling shell commands.

Neglecting to sanitize user input that may subsequently be passed to system-level functions could allow attackers to do massive internal damage to your information store and operating system, deface or delete Web files, and otherwise gain unrestricted access to your server. And that's only the beginning.

He starts with a "real world" example of non-filtered data that could pass through a "rm" command and erase your entire drive. He offers two solutions for preventing this sort of hack using the escapeshellcmd and escapeshellarg functions.

Gareth Heyes has tried out an interesting experiment - running non-alphanumeric code in PHP using only octal escapes.

So a small php shell was tweeted around and it inspired me to investigate a way to execute non-alphanumeric code. First off I started with the idea of using octal escapes in PHP and constructing the escape so for example: 107 is "G" if I could construct the "107" and add the backslash to the beginning maybe I could construct "G".

A snippet of example code is included showing his octal-based code for creating a "G" (6 lines of pluses, parentheses, equals and a few more characters). By doing some trickery with bitwise operators on strings, he was able to combine characters and make the string "GET". Pretty clever, even if it's not entirely practical.

In his (Python) blog today Casey reminds the developer community about a handy tool that the developers at Facebook have made available to make a PHP coder's life easier - phpsh.

The developers at Facebook have brought PHP developers a powerful REPL now ala-Python to round out a solid toolbox that PHP developers already have. The project is called phpsh and is written in Python.

He includes the commands you'll need to get it pulled from github and working, providing you with an interactive shell right on your local machine (more powerful than the built-in PHP shell). You can also grab a zip or gzipped archive for download. For complete details on the tool and how to use it, see phpsh.org.

Jordi Boggiano has a new post today looking at his PHP console script that works in your browser that sets up easily and works from your localhost web server - php-console.

Since I spend most of my days programming PHP I tend to need that a lot and a few years back I wrote a small script that would let me type php code in my browser and execute it. Nothing fancy, but quite useful. Over the years a few people got interest seeing me use it and asked for the sources, so instead of repackaging it every time, I thought I'd clean it up, polish a bit, add some features, and put it on github.

Setup is as simple as dropping the code somewhere in your local server's document root and offers a textarea for input and a expandable tree for the resulting output. It uses the Krumo tool to create this modified output. You can see a screenshot here.

Johannes Schluter has a new post to his blog today about a recent addition to the latest trunk branch for PHP - a more interactive shell that will be installed right along with the language.

A few years ago I used another blog to write about "More PHP power on the command line" almost 5 years later the PHP interactive shell got a major update which went in PHP's trunk.

You can check out the commit message for more details on this new addition including paging ability and the ability to run PHP directly in the shell.