Download the PHP package ptlis/shell-command without Composer

ptlis/shell-command

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.

• Install
• Usage
  • The Builder
    • Set Command
    • Set Process Timeout
    • Set Poll Timeout
    • Set Working Directory
    • Add Arguments
    • Add Raw Arguments
    • Add Environment Variables
    • Add Process Observers
    • Build the Command
  • Synchronous Execution
  • Asynchronous Execution
    • Command::runAsynchronous
  • Process API
    • Process::getPromise
• Mocking
• Contributing
• Known limitations

Install

From the terminal:

Usage

The Builder

The package ships with a command builder, providing a simple and safe method to build commands.

The builder will attempt to determine your environment when constructed, you can override this by specifying an environment as the first argument:

Note: this builder is immutable - method calls must be chained and terminated with a call to like so:

Set Command

First we must provide the command to execute:

If the command is not locatable a is thrown.

Set Process Timeout

The timeout (in microseconds) sets how long the library will wait on a process before termination. Defaults to -1 which never forces termination.

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 Poll Timeout

Set how long to wait (in microseconds) between polling the status of processes. Defaults to 1,000,000 (1 second).

Set Working Directory

You can set the working directory for a command:

Add Arguments

Add arguments to invoke the command with (all arguments are escaped):

Conditionally add, depending on the result of an expression:

Add several arguments:

Conditionally add, depending on the result of an expression:

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.

Add Raw 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:

Conditionally, depending on the result of an expression:

Add several raw arguments:

Conditionally, depending on the result of an expression:

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.

Add Environment Variables

Environment variables can be set when running a command:

Conditionally, depending on the result of an expression:

Add several environment variables:

Conditionally, depending on the result of an expression:

Add Process Observers

Observers can be attached to spawned processes. In this case we add a simple logger:

Build the Command

One the builder has been configured, the command can be retrieved for execution:

Synchronous Execution

To run a command synchronously use the method. This returns an object implementing , encoding the result of the command.

When you need to re-run the same command multiple times you can simply invoke 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:

Asynchronous Execution

Commands can also be executed asynchronously, allowing your program to continue executing while waiting for the result.

Command::runAsynchronous

The method returns an object implementing the which provides methods to monitor the state of a process.

As with the synchronouse API, when you need to re-run the same command multiple times you can simply invoke repeatedly; each call will run the command returning the object representing the process to your application.

Process API

provides the methods required to monitor and manipulate the state and lifecycle of a process.

Check whether the process has completed:

Force the process to stop:

Wait for the process to stop (this blocks execution of your script, effectively making this synchronous):

Get the process id (throws a if the process has ended):

Read output from a stream:

Provide input (e.g. via STDIN):

Get the exit code (throws a if the process is still running):

Send a signal (SIGTERM or SIGKILL) to the process:

Get the string representation of the running command:

Process::getPromise

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 method from a instance. This returns an instance of :

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 :

This will block further execution until the promises are resolved/rejected.

Mocking

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.

Contributing

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.

Known limitations

• Supports UNIX environments only.