A developer-friendly wrapper around execution of shell commands.
There were several goals that inspired the creation of this package:
- Use the command pattern to encapsulate the data required to execute a shell command, allowing the command to be passed around and executed later.
- Maintain a stateless object graph allowing (for example) the spawning of multiple running processes from a single command.
- Provide clean APIs for synchronous and asynchronous usage.
- Running processes can be wrapped in promises to allow for easy composition.
From the terminal:
$ composer require ptlis/shell-command
The package ships with a command builder, providing a simple and safe method to build commands.
use ptlis\ShellCommand\CommandBuilder;
$builder = new CommandBuilder();
The builder will attempt to determine your environment when constructed, you can override this by specifying an environment as the first argument:
use ptlis\ShellCommand\CommandBuilder;
use ptlis\ShellCommand\UnixEnvironment;
$builder = new CommandBuilder(new UnixEnvironment());
Note: this builder is immutable - method calls must be chained and terminated with a call to buildCommand
like so:
$command = $builder
->setCommand('foo')
->addArgument('--bar=baz')
->buildCommand()
First we must provide the command to execute:
$builder->setCommand('git') // Executable in $PATH
$builder->setCommand('./local/bin/git') // Relative to current working directory
$builder->setCommand('/usr/bin/git') // Fully qualified path
$build->setCommand('~/.script.sh') // Path relative to $HOME
If the command is not locatable a RuntimeException
is thrown.
The timeout (in microseconds) sets how long the library will wait on a process before termination. Defaults to -1 which never forces termination.
$builder
->setTimeout(30 * 1000 * 1000) // Wait 30 seconds
If the process execution time exceeds this value a SIGTERM will be sent; if the process then doesn't terminate after a further 1 second wait then a SIGKILL is sent.
Set how long to wait (in microseconds) between polling the status of processes. Defaults to 1,000,000 (1 second).
$builder
->setPollTimeout(30 * 1000 * 1000) // Wait 30 seconds
You can set the working directory for a command:
$builder
->setCwd('/path/to/working/directory/')
Add arguments to invoke the command with (all arguments are escaped):
$builder
->addArgument('--foo=bar')
Conditionally add, depending on the result of an expression:
$builder
->addArgument('--foo=bar', $myVar === 5)
Add several arguments:
$builder
->addArguments([
'--foo=bar',
'-xzcf',
'if=/dev/sda of=/dev/sdb'
])
Conditionally add, depending on the result of an expression:
$builder
->addArguments([
'--foo=bar',
'-xzcf',
'if=/dev/sda of=/dev/sdb'
], $myVar === 5)
Note: Escaped and raw arguments are added to the command in the order they're added to the builder. This accommodates commands that are sensitive to the order of arguments.
WARNING: Do not pass user-provided data to these methods! Malicious users could easily execute arbitrary shell commands.
Arguments can also be applied without escaping:
$builder
->addRawArgument("--foo='bar'")
Conditionally, depending on the result of an expression:
$builder
->addRawArgument('--foo=bar', $myVar === 5)
Add several raw arguments:
$builder
->addRawArguments([
"--foo='bar'",
'-xzcf',
])
Conditionally, depending on the result of an expression:
$builder
->addRawArguments([
'--foo=bar',
'-xzcf',
'if=/dev/sda of=/dev/sdb'
], $myVar === 5)
Note: Escaped and raw arguments are added to the command in the order they're added to the builder. This accommodates commands that are sensitive to the order of arguments.
Environment variables can be set when running a command:
$builder
->addEnvironmentVariable('TEST_VARIABLE', '123')
Conditionally, depending on the result of an expression:
$builder
->addEnvironmentVariable('TEST_VARIABLE', '123', $myVar === 5)
Add several environment variables:
$builder
->addEnvironmentVariables([
'TEST_VARIABLE' => '123',
'FOO' => 'bar'
])
Conditionally, depending on the result of an expression:
$builder
->addEnvironmentVariables([
'TEST_VARIABLE' => '123',
'FOO' => 'bar'
], $foo === 5)
Observers can be attached to spawned processes. In this case we add a simple logger:
$builder
->addProcessObserver(
new AllLogger(
new DiskLogger(),
LogLevel::DEBUG
)
)
One the builder has been configured, the command can be retrieved for execution:
$command = $builder
// ...
->buildCommand();
To run a command synchronously use the runSynchronous
method. This returns an object implementing CommandResultInterface
, encoding the result of the command.
$result = $command
->runSynchronous();
When you need to re-run the same command multiple times you can simply invoke runSynchronous
repeatedly; each call will run the command returning the result to your application.
The exit code & output of the command are available as methods on this object:
$result->getExitCode(); // 0 for success, anything else conventionally indicates an error
$result->getStdOut(); // The contents of stdout (as a string)
$result->getStdOutLines(); // The contents of stdout (as an array of lines)
$result->getStdErr(); // The contents of stderr (as a string)
$result->getStdErrLines(); // The contents of stderr (as an array of lines)
$result->getExecutedCommand(); // Get the executed command as a string, including environment variables
$result->getWorkingDirectory(); // Get the directory the command was executed in
Commands can also be executed asynchronously, allowing your program to continue executing while waiting for the result.
The runAsynchronous
method returns an object implementing the ProcessInterface
which provides methods to monitor the state of a process.
$process = $command->runAsynchronous();
As with the synchronouse API, when you need to re-run the same command multiple times you can simply invoke runAsynchronous
repeatedly; each call will run the command returning the object representing the process to your application.
ProcessInterface
provides the methods required to monitor and manipulate the state and lifecycle of a process.
Check whether the process has completed:
if (!$process->isRunning()) {
echo 'done' . PHP_EOL;
}
Force the process to stop:
$process->stop();
Wait for the process to stop (this blocks execution of your script, effectively making this synchronous):
$process->wait();
Get the process id (throws a \RuntimeException
if the process has ended):
$process->getPid();
Read output from a stream:
$stdOut = $process->readStream(ProcessInterface::STDOUT);
Provide input (e.g. via STDIN):
$process->writeInput('Data to pass to the running process via STDIN');
Get the exit code (throws a \RuntimeException
if the process is still running):
$exitCode = $process->getExitCode();
Send a signal (SIGTERM or SIGKILL) to the process:
$process->sendSignal(ProcessInterface::SIGTERM);
Get the string representation of the running command:
$commandString = $process->getCommand();
Monitoring of shell command execution can be wrapped in a ReactPHP Promise. This gives us a flexible execution model, allowing chaining (with Promise::then) and aggregation using Promise::all, Promise::some, Promise::race and their friends.
Building promise to execute a command can be done by calling the getPromise
method from a Process
instance. This returns an instance of \React\Promise\Promise
:
$eventLoop = \React\EventLoop\Factory::create();
$promise = $command->runAsynchonous()->getPromise($eventLoop);
The ReactPHP EventLoop component is used to periodically poll the running process to see if it has terminated yet; once it has the promise is either resolved or rejected depending on the exit code of the executed command.
The effect of this implementation is that once you've created your promises, chains and aggregates you must invoke EventLoop::run
:
$eventLoop->run();
This will block further execution until the promises are resolved/rejected.
Mock implementations of the Command & Builder interfaces are provided to aid testing.
By type hinting against the interfaces, rather than the concrete implementations, these mocks can be injected & used to return pre-configured result objects.
You can contribute by submitting an Issue to the issue tracker, improving the documentation or submitting a pull request. For pull requests i'd prefer that the code style and test coverage is maintained, but I am happy to work through any minor issues that may arise so that the request can be merged.
- Supports UNIX environments only.