Objects of the class Process use standard process-executing functions, like members of the execl(2) family or sh(1) to execute child processes. Thus, child processes can be executable programs or shell-scripts.
The standard input, output and error streams of child processes may be accessed through their Process parent objects. Input expected by child processes may be inserted by Process objects, and output generated by child processes may be extracted from Process objects.
When using (output) redirection with the USE_SHELL path specification (see below for the path and IOMode specifications), the IGNORE_COUT IOMode (and possibly IGNORE_CERR) should normally be specified.
Process objects may repeatedly be used to execute the same or different child processes. Before the next child process is started, the Process object first terminates its currently active child process. Alternatively, a currently active child process is automatically ended if the Process object goes out of scope, if its stop or eoi (end-of-information) member is called, or if the eoi manipulator is inserted into the Process object.
Programs called as child processes may be specified when constructing a Process object or by using Process's setCommand member. Process constructors (or Process set-members) never start child processes. Child processes are started through start members or the assignment operator.
Child processes may receive information at their standard input streams through information inserted into Process objects. In these cases the Process objects must inform their child processes that they have received all input. For this the close or eoi member or the eoi manipulator can be used. After calling the close member, the waitForChild member should be called as well. This is not necessary if either the eoi member or the eoi manipulator is used.
If waitForChild is not called (but information sent to the child which could not be fully processed by the child process in case the child process terminated as a result of the Process object going out of scope), then the operating system issues a Broken pipe message, indicating that information in a pipe was lost.
Arguments passed to child processes may be surrounded by double or single quotes. Arguments surrounded by double quotes have their double quotes removed, while interpreting any escape-sequences that may have been used within. Arguments surrounded by single quotes have their single quotes removed, while accepting their content as-is. In addition unquoted escape-sequences may be specified: those escape sequences are evaluated and replaced by their intended characters (e.g., \100 is converted to @).
A full command specification may be surrounded by backtics (`-characters). These backtick characters are removed by the Process object when the command is started.
Child processes may be allowed a limited amount of time (in seconds) to complete. By default no time limit is imposed upon child processes.
By default the standard input, output and error streams of child processes are accessed through their Process parent processes: information inserted into the Process object is forwarded to the child process's standard input stream, information sent by the child process to its standard output stream can be extracted from its parent Process object, and information sent by the child process to its standard error stream may be obtained through Process's childErrStream member.
If the parent and child processes have agreed on some communication process, then information may alternatingly be sent to and received from the child process through the Process's ostream and istream facilities. Alternatively, unspecified amounts of information written by child processes may be processed by separate threads (cf. this manual page's EXAMPLES section).
Process objects use Pipe objects (cf. pipe(3bobcat)) for communication with its child processes. To ensure that these pipes are properly closed the members waitForChild, stop or the eoi manipulator should be used. Once a Process object ceases to exist pipes to its child process are also closed.
The struct ProcessEnums defines enumerations and support functions which are used by several classes. Its enumerations are documented below; there is no separate ProcessEnums man-page.
enum ProcessType:
The enum ProcessType defines how a child process is started or located. Its values are specified at constructor-time or through the setProcessType member. This enumeration defines the following symbolic constants:
enum IOMode:
Values of the enum IOMode are used to define which of the child process's standard streams can be accessed through the Process object. Its symbolic constants may be combined using the bit_or operator. By default CIN | COUT | CERR is used (see below).
The following symbolic constants are available:
enum ChildOutput:
The ChildOutput enumeration defines values returned by the
available member (see below) indicating to which standard stream the
child process has written information. This enumeration defines the following
values:
Four process parameters may be specified: the sizes of the stream buffers which are used when communicating with child processes; to specify which of the standard streams of child processes can be accessed from the Process object combinations of IOMode values are used; to specify how child programs are found a ProcessType value is used; to specify the maximum time (in seconds) the child program is allowed to run a size_t values is used.
By default, the stream buffers hold 200 bytes; all the child's standard streams (standard input, output and error) are accessible from the Parent process; the PATH environment variable is not used to locate the child program; and the child processes will be allowed an unlimited amount of time to run.
After constructing a Process object all default parameters may be modified. These parameters may either be altered for a single process or a Process object's general defaults may be modified. The set* members (see below) may be used to change the default process parameters. When parameters are specified otherwise, they will only be active for the next process.
The command provided to the following constructors may be the (initial part of the) specification of an external program to run. When the program is eventually started it may start and end with a back-tick (`). The back-ticks will be removed just before the specified program is executed.
Child processes are not started automatically following Process object constructions. A start member or the assignment operator (see below) is used to start the specified child process.
Constructors expecting an IOMode argument may be provided with multiple IOMode values by combining them using the bit-or operator.
After constructing a Process object its parameters can be changed using set-member functions, function call operators or start members.
Copy and move constructors (and assignment operators) are not available.
Before starting the child process a possibly active child process is first stopped by calling stop. It returns stop's return value. Immediately after calling stop the new command (cmd) is started. If stopping and restarting another command should be separate actions then use stop, followed by setCommand, followed by calling an appropriate overloaded version of the member start (start() uses the object's current IOMode, ProcessType, and time limit).
process(Process::COUT) = "/bin/cat";
to start a new child process with the specified IOMode.
This operator mimics the piping-operator supported by most command-shell programs and should not be confused with the binary-or operator. The operator starts the lhs's child process, but the rhs's child process (and thus pipe processing) must explicitly be started.
Since operator| is left-associative and rhs is returned piping can be chained, allowing constructions like p1 | p2 | p3, where p1, p2 and p3 are Process objects.
The following idiom can be used to start the execution of a chain of processes: (p1 | p2 | p3).start(). Alternatively, the following two-step procedure can be used:
p1 | p2 | p3;
p3.start();
If p1 specifies Process::CIN then this IOMode is forwared to the final process of the chain of processes. It is not necessary to specify Process::CIN for p3. In fact, most IOMode flags of processes passed to operator| are ignored or modified. Acceptable IOModes are Process::IGNORE_CERR and Process::CERR (accepted for all processes), Process::CIN (accepted for the first process of the chain), and Process::COUT (for the last process of the chain).
Note: when connecting a series of processes using operator| all input and output (except for the standard error streams) is handled through the last process: if Process::CIN is specified for the first process then this mode is transferred to the last process, so information inserted into the last process enters the pipe through the first process's standard input.
The next example illustrates how input can be inserted into the first process from a main process and sent to the standard output stream by the final process:
using namespace std;
using namespace FBB;
Process p1(Process::CIN, "/bin/cat");
Process p2("/bin/cat");
Process p3(Process::NONE, "/bin/cat");
p1 | p2 | p3;
p3.start();
p3 << cin.rdbuf() << eoi;
When joining multiple commands using the piping operator ('|'), the
process type USE_SHELL is not required, even though process-piping is
commonly used as a shell-feature. Process's operator| handles I/O piping
itself, and thus can avoid the additional shell process.
if (process.available() & Process::CHILD_COUT)
cout << "Process has child standard output available";
cout << process.childOutStream().rdbbuf()