FBB::Process(3bobcat)

📦
version 6.15.01 · 7 versions
, in ubuntu stonking

💖 NAME 💖

FBB::Process(3bobcat) — Running Child Processes

FBB::Process runs external programs. That's the whole job description bestie. 💅

✨ SYNOPSIS ✨

#include <bobcat/process>
Linking option: -lbobcat

🦋 DESCRIPTION 🦋

okay so, FBB::Process is literally the class that gives you an extensive interface for calling external programs and/or scripts from a C++ program — we're talking child processes, the whole thing. And the way it does it? An easy-to-use, stream-based interface to the standard input, standard output and standard error streams of child processes. Obsessed, honestly. 😭

Objects of the class Process use standard process-executing functions, like members of the execl(2) family or sh(1), to execute child processes. So a child process can be an executable program or a shell-script. Both slay. ✨

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. Two-way street energy fr fr. 🫶

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. Do not skip this one bestie, it's giving consequences. 💀

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. Automatic cleanup? We love to see it. 🧚

Programs called as child processes may be specified when constructing a Process object or by using Process's setCommand member. Important lore: Process constructors (or Process set-members) never start child processes. Child processes are started through start members or the assignment operator. No sneaky auto-launching here. 🎀

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. Noted and memorized. 👑

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. Yeah that's not the vibe. 😭

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 @). Quoting lore, iykyk. 💅

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. Live your truth, little child process. 🕐

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. Default behaviour is honestly iconic. 🌈

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). Multithreading moment, bestie. 🦋

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. ✨

🌈 NAMESPACE 🌈

FBB

All constructors, members, operators and manipulators, mentioned in this man-page, are defined in the namespace FBB.

👑 INHERITS FROM 👑

FBB::Fork(3bobcat) (private), FBB:IOStream(3bobcat), and by implication: FBB::Eoi, FBB:ProcessEnums

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.

💜 ENUMERATIONS 💜

🌸 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:

  • NO_PATH: The program specified as child process is started as specified, without searching the elements of the PATH environment variable.
  • USE_PATH: The elements of the PATH environment variable are used when locating the program specified as child process.
  • USE_SHELL: The program specified as child process is called using /bin/sh -c. When (output) redirection is used with the specified command the IGNORE_COUT IOMode (and possibly also the IGNORE_CERR IOMode) should be specified.

🌟 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:

  • ALL: Shortcut for CIN | COUT | CERR.
  • CIN: Information inserted into the Process object is forwarded to its child process. If this is not required then CIN should not be specified.
  • CERR: Information written by the child process to its standard error stream is accessible through Process's childErrStream member. If this is not required then CERR should not be specified.
  • COUT: Information written by the child process to its standard output stream may be directly be extracted from the Process object, or from its childOutStream member. If this is not required then COUT should not be specified.
  • DIRECT: When starting a child process (see below at the member start) the current process (i.e., the program defining the Process object) is replaced by the child process, inheriting the current process's standard input and output streams. If this mode is specified in combination with any other IOMode (except for NONE, see below) an std::invalid_argument exception is thrown.
  • IGNORE_CERR: Information written by the child process to its standard error stream is sent to /dev/null. An std::invalid_argument exception is thrown if this mode is specified in combination with DIRECT, CERR and/or MERGE_COUT_CERR.
  • IGNORE_COUT: Information written by the child process to its standard output stream is sent to /dev/null. An std::invalid_argument exception is thrown if this mode is specified in combination with COUT, DIRECT and/or MERGE_COUT_CERR.
  • IGNORE_COUT_CERR: Shortcut for IGNORE_CERR | IGNORE_COUT.
  • MERGE_COUT_CERR: Information extracted from the Process object is written by the child process to its standard output and standard error streams. An std::invalid_argument exception is thrown if this mode is specified in combination with COUT, CERR, DIRECT, IGNORE_COUT or IGNORE_CERR.
  • NONE: The Process object does not extract information from or insert information into the standard streams of its child process. The child process reads the same standard input stream and writes the same standard output streams as its parent Process object. When this mode is specified in combination with other IOMode values it is silently ignored.

🎀 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:

  • NOTHING_AVAILABLE: The child process did not (yet) write any information to its standard streams;
  • CHILD_COUT: The child process wrote information to its standard output stream which is waiting for extraction.
  • CHILD_CERR: The child process wrote information to its standard error stream which is waiting for extraction. The latter two values may be combined using the bit_or operator. The bit_and operator, returning a bool value, can be used to test whether information on a specific output stream is available.

🧚 PROCESS PARAMETERS 🧚

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. Defaults ate, no cap. 🍓

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. Main character energy: one process at a time. 💅

✨ CONSTRUCTORS ✨

okay so first things first bestie 🫶 the command you hand to any of these constructors can be the (initial part of the) specification of an external program to run. and here's the lil quirky detail: when the program is eventually started it may start and end with a back-tick (`). those back-ticks get removed just before the specified program is executed. cute, right? 🎀

child processes are not started automatically when you construct a Process object. nope. not even a little bit. you gotta use a start member or the assignment operator (more on that below 👇) to actually start the specified child process. no auto-start energy here, it's giving patient.

constructors that expect an IOMode argument? you can hand them multiple IOMode values by combining them with the bit-or operator. stack 'em like accessories 💅

and after you've constructed a Process object, its parameters can be changed using set-member functions, function call operators, or start members. very flexible, we love a glow-up arc.

  • Process(std::string const &cmd = "") — this one is for specifying the (initial part of a) command to execute from a Process object. the process parameters all get their default values (peep the PROCESS PARAMETERS section for those).
  • Process(IOMode mode, std::string const &cmd = "") — this one requires you to specify the object's IOMode, and it can also specify the (initial part of a) command to execute from a Process object. the remaining process parameters get default values (again: PROCESS PARAMETERS section).
  • Process(IOMode mode, ProcessType type, std::string const &cmd = "") — this one requires both the object's IOMode and ProcessType, and can specify the (initial part of a) command to execute. remaining process parameters = defaults (PROCESS PARAMETERS, go look).
  • Process(IOMode mode, ProcessType type, size_t timeLimit, std::string const &cmd = "") — this one requires the object's IOMode, ProcessType, and child process time limit. the (initial part of a) command to execute from a Process object is optional here. the default process parameter is used for the sizes of the internally used stream buffers (PROCESS PARAMETERS, you know the drill).
  • Process(IOMode mode, ProcessType type, size_t timeLimit, size_t bufferSize, std::string const &cmd = "") — this one requires the object's IOMode, ProcessType, child process time limit, and size of the internally used stream buffers. the (initial part of a) command to execute is optional again. ⚠️ note that this constructor's mode parameter does not accept a size_t argument.

copy and move constructors (and assignment operators) are not available. not a thing. don't try it. 🚫

💥 OVERLOADED OPERATORS 💥

  • Process &operator<<(Type value) — this operator inserts value into the child's standard input stream. i.e., the child process reads value from its standard input. any type that can be inserted into an ostream can be inserted into a Process object. and if you use this member when the child process has already terminated? nothing happens. zilch. also manipulators like std::endl are supported 🎉. BUT — the behavior of this operator is undefined unless IOMode CIN was specified. so specify it, bestie, or chaos ensues 💀.
  • Process &operator>>(Type value) — this one extracts value from the child's standard output stream, and optionally (if IOMode MERGE_COUT_CERR was specified) from the child's error stream. i.e., value may be extracted from Process objects. any type that can be extracted from an istream can be extracted from a Process object. nothing happens if you use this member when the child process has terminated. and again, the behavior of this operator is undefined unless IOMode COUT or MERGE_COUT_CERR was specified — respect the rules or face the consequences 🙈.
  • Process &operator+=(std::string const &) — this operator adds the provided std::string object to the currently defined command specification of a Process object. heads up though: operator+= does not add a separating blank space between the currently stored command specification and the text to append. it merely adds its right-hand side string to the command stored so far. and it does not affect a currently running child process. so if you need a space, add it yourself, bestie, it's not gonna do it for you 😭.
  • int operator=(std::string const &cmd) — the operator= member defines cmd as the stored command in a Process object.

before starting the child process, a possibly active child process is first stopped by calling stop. it returns stop's return value. and 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). your call, queen 👑.

  • Process &operator()(IOMode mode) — this operator changes the Process object's IOMode parameter. a reference to the Process object is returned, which allows constructions like
process(Process::COUT) = "/bin/cat";

to start a new child process with the specified IOMode. slay ✨

  • Process &operator()(IOMode mode, ProcessType type) — this operator changes the Process object's IOMode and ProcessType process parameters.
  • Process &operator()(IOMode mode, ProcessType type, size_t timeLimit) — this operator changes the Process object's mentioned process parameters. the currently specified default size of the stream buffers is kept as-is. untouched. preserved. 🫶
  • Process &operator()(IOMode mode, ProcessType type, size_t timeLimit, size_t bufferSize) — this operator changes all of the Process object's process parameters. every single one. full makeover 💅
  • Process &operator|(Process &lhs, Process &rhs) — this operator implements process piping: information sent by lhs to its standard output becomes the rhs's standard input. the operator returns rhs.

this operator mimics the piping-operator supported by most command-shell programs and should not be confused with the binary-or operator. important distinction, don't mix them up 🙅

the operator starts the lhs's child process, but the rhs's child process (and thus pipe processing) must explicitly be started. it won't do that part for you.

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. chain them like friendship bracelets 🦋.

the following idiom can be used to start the execution of a chain of processes: (p1 | p2 | p3).start(). alternatively, this two-step procedure works too:

p1 | p2 | p3;
p3.start();

if p1 specifies Process::CIN then this IOMode is forwarded 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. the 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. iykyk 🌈

the next example shows 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. efficient icon behavior ✨

🫶 MEMBERS 🫶

  • bool active() — this member returns true if the child process is currently running and false if not. simple as that, a little vibe check on your process 💅.
  • size_t available() — this member returns immediately. its return value indicates whether any information can be obtained from the child process as value(s) from the enum ChildOutput. NOTHING_AVAILABLE is returned if no information is ready for extraction. CHILD_COUT is returned if information from the child process's standard output stream is available; CHILD_CERR is returned if information from the child process's standard error stream is available; CHILD_COUT | CHILD_CERR is returned if information from both the standard output and standard error streams is available. the bit_and operator, returning a bool value, can be used to determine which stream has any pending information. like this:
if (process.available() & Process::CHILD_COUT)
    cout << "Process has child standard output available";
  • size_t bufSize() const — this member returns the default size of the stream buffers that are used for communication with child processes. ⚠️ but here's the tea: if called while a child process is actually running, then the value returned by this member may differ from the value that was actually used when starting the child process, since the default value may be altered by a function call operator just before starting the child process. so don't be shocked if the numbers don't match up 😭.
  • std::istream &childErrStream() — if Process::CERR was specified then this member interfaces to the child's standard error stream. by extracting the information from childErrStream the parent process retrieves the information sent by its child process to its standard error stream. catching those stderr vibes 🎀
  • std::istream &childOutStream() — so if you told the Process Process::COUT or Process::MERGE_COUT_CERR, this member is your little doorway to the child's standard output stream 💖. You pull the info out of childOutStream and boom, that's what your child process sent to its stdout. You could also slurp that data straight off the Process object itself, but this member means you don't have to bust out a static_cast just to clear up which stream buffer you're talking about, in statements like:
cout << process.childOutStream().rdbbuf()
  • void close() — closes the child's input stream 🚪. When your child is sitting there in a loop reading from its standard input, this is how you tell it "bestie, input is DONE". 👑 Only use this when IOMode CIN was set for the child process currently running — any other time the behavior is undefined. No cap. You can also reach for the eoi member or the eoi manipulator instead.
  • int eoi() — closes the child's input stream, then calls waitForChild to hang around until the child process actually ends 🫶. Same deal as close for the "child keeps reading stdin" situation, same "only when IOMode CIN was specified for the currently running child process" rule — otherwise undefined behavior, and same alternative: use the close member or the eoi manipulator. What you get back is the exit-status of the child process that got called. ✨
  • int exitStatus() const — once you've called eoi or shoved the eoi manipulator into the Process object, this hands you the child's exit status 🎀. Any other time? The value it gives back is not defined, so please just use waitForChild instead, okay?
  • IOMode ioMode() const — returns the default IOMode 🌸. Heads up though: if you call this while a child is actually running, what you get back might not match what was really used when that child started, because a function call operator may have changed the default right before the process launched. Sneaky!
  • ProcessType processType() const — returns the default ProcessType of child processes 🦋. Same energy as above: call it while a child is running and the returned value may differ from what was actually used, since a function call operator could have switched up the default just before the child started.
  • size_t timeLimit() const — returns the default time limit, in seconds, for child processes ⏳. A return of zero means no time limit is enforced at all, go wild. And yep, same caveat: if a child is currently running, the returned value may not be the one that was actually used, because a function call operator may have changed the default right before starting it.
  • void setBufSize(size_t bufSize) — changes the default stream buffer size used to talk to child processes 📦. A zero-byte buffer size gets silently bumped up to one (no drama, it just happens). Your new default kicks in when you start the next child process.
  • void setCommand(std::string const &cmd) — (re)defines the (initial part of a) child process command specification ✍️.

Important: this does not actually start the child process. You can use operator+= to tack more text onto the command spec. Also, you can call this while a child process is active — it does not affect the currently running child. Zero harm, zero interference. 💅

  • void setIOMode(iomode mode) — changes the default IOMode 🌈. The new default gets used when you start the next child process.
  • void setProcessType(ProcessType type) — changes the default ProcessType 👑. New default, next child process, you know the drill.
  • void setTimeLimit(size_t timeLimit) — changes the default execution time limit, in seconds ⏰. Specify timeLimit 0 and no time limit will be imposed on child processes at all. The new default applies when you start the next child process.
  • void start() — starts the currently specified command using the Process object's process parameters 🚀.

Once you've set a command, the first white-space delimited element of it is what gets used as the name of the program to start. If you want that program called through sh(1), then use the USE_SHELL ProcessType or a system member instead. Periodt.

If a child process won't terminate on its own, it gets terminated: when it's run for its alloted time; when the Process object's start or stop members are called; when the object's assignment operator is used; or when the object goes out of scope. 😭

Alternatively, you may have to call waitForChild (see below) to actually end a running process.

  • void start(IOMode mode) — starts the currently specified command using the specified IOMode, but otherwise using the currently configured Process object's process parameters ✨. That IOMode only applies to the child process started by this member, and only this one.
  • void start(IOMode mode, ProcessType type) — starts the currently specified command using the specified IOMode and ProcessType, but otherwise using the currently configured Process object's process parameters 🌟. Again: those specified values apply only to the child process this member starts.
  • void start(size_t mode, Program program, size_t timeLimit) — starts the currently specified command using the specified IOMode, ProcessType, and time limit (quietly converting that size_t mode into an IOMode value 💫), plus the currently configured Process object's stream buffer size parameter. Specified values = only for the child started by this member.
  • void start(IOMode mode, Program program, size_t timeLimit, size_t bufferSize) — starts the currently specified command using the specified process parameters 🔥. Yep, specified values are only for the child process this member starts.
  • void showMode(char const *lab) const — shows off the label lab, then the current process ID, then the child process's process ID, then a textual representation of the currently active IOMode 🎀. Little receipt of what's going on.
  • std::string const &str() const — returns the content of the current child process command specification 📜. Basically it shows you the command exactly as it will be (or has been) executed by start, system, or the assignment operator.
  • void system() — executes the currently stored command as a command to sh(1) 🐚. When you use system, redirections can live right there in the command itself — which renders the redirected streams implied by the current IOMode useless. The currently set process parameters are used when sh(1) runs.
  • void system(IOMode mode) — executes the currently stored command as a command to sh(1) (see system above 💖) using the specified IOMode instead of whatever the current default IOMode setting is.
  • void system(IOMode mode, size_t timeLimit) — executes the currently stored command as a command to sh(1) (cf. system above) using the specified IOMode and time limit ⏳.
  • void system(IOMode mode, size_t timeLimit, size_t bufSize) — executes the currently stored command as a command to sh(1) (cf. system above) using the specified IOMode, time limit, and stream buffer size values 🧚.
  • int stop() — terminates a currently active child process 💀. Here's the sequence, and it is not gentle: the child process is twice sent a SIG_TERM signal, followed by a SIG_KILL signal. This member returns the exit-value of the child process that was stopped. And if you call it without a running child process? Its operation and return value are undefined — so don't. 🙈

After stop, you can fire up a new command using start, system, or the assignment operator (see earlier). Those members call stop themselves first. So when your plan is just to start another child process, there's literally no need to call stop yourself, bestie 😌. Also, stop gets called when the Process object goes out of scope.

  • int waitForChild() — calls the identically named member from the class FBB::Fork 🫂, waiting for a child process to end. You call it to prevent a child process from terminating prematurely before you call stop. But ngl, it's not always necessary: e.g., when a process writes to its standard output stream and all of that output has been read, then the child process can be stopped without calling waitForChild at all. ✨

✨ MANIPULATOR ✨

  • FBB::eoi — this manipulator can be inserted into a Process object that had IOMode CIN specified 🎀. It closes the child's input stream, and then calls waitForChild to wait for the child process to end. When your child keeps reading from its standard input stream, this is the girl that tells it input has terminated 👑. Alternatively, the Process object's close or eoi members may be used.

✨ EXAMPLES ✨

okay bestie, grab a snack because these examples are so cute and they actually teach you everything 💖

Example 1: the "I just want the output" girlie 🌸

This first one shows how you call a program that only produces output — no talking back, just vibes. Its child process is literally just /bin/ls:

int main()
{
    Process process(Process::COUT, "/bin/ls -Fla");

    process.start();
    cout << process.childOutStream().rdbuf();
}

see how it's giving minimal effort but maximum slay? you hand Process::COUT the flag, you hand it the command "/bin/ls -Fla", you start() it, and then you just slurp up the child's output stream with rdbuf(). iconic. no notes. 💅

Example 2: the "you have 5 seconds, bestie" one ⏰

The next example shows how a child program can be given a limited amount of execution time. Lines entered at the keyboard get echoed to the standard output stream — but only for at most 5 seconds:

int main()
{
    Process process(Process::CIN | Process::COUT, "/bin/cat");
    process.setTimeLimit(5);

    process.start();

    while (true)
    {
        cout << "? ";
        string line;
        if (not getline(cin, line))
            return 0;

        process << line << endl;           // to /bin/cat
        line.clear();

        if (not getline(process, line))    // from /bin/cat
            break;

        cout << "Received: " << line << endl;
    }

    cout << "/bin/cat time limit of 5 seconds reached: child process ended\n";
}

lowkey obsessed with this one actually. Process::CIN | Process::COUT means both directions are open (it's a two-way street, fr fr), and setTimeLimit(5) is the girlboss boundary-setting moment: 5 seconds and then we're DONE. the loop reads from cin, shoves the line into the child with process << line << endl; (there's your little // to /bin/cat note), clears the string, then reads back with getline(process, line) (that's the // from /bin/cat moment) and prints it. when the time limit hits, you get that final line about /bin/cat's 5 second time limit being reached. periodt. 🫶

Example 3: the multithreading main character energy 👑

The final example shows how multi threading can be used to access the child program's standard output and standard error streams through the Process object. two streams, two threads, one very capable girlie:

void collect(ostream *outStream, streambuf *rdbuf)
{
    *outStream << rdbuf << flush;
}

int main()
{
    string cmd(getcwd(0, 0));
    cmd += "/cincoutcerr";

    Process all(Process::ALL, cmd);

    all.start();

    thread outThread(collect, &cout, all.childOutStream().rdbuf());
    thread errThread(collect, &cerr, all.childErrStream().rdbuf());

    all << cin.rdbuf() << eoi;

    outThread.join();
    errThread.join();
}

okay so the whole plot: you build the command from getcwd(0, 0) and slap "/cincoutcerr" on the end of it, you spin up a Process with Process::ALL (all three streams, we love an overachiever 💖), you start() it, then you launch a thread for the child's out stream and another for the child's err stream — both running that collect helper, which pipes the streambuf into the ostream and flushes. meanwhile the main thread pushes cin.rdbuf() into the process and seals it with eoi. then you join() both threads because we do NOT leave threads hanging, bestie, that's so rude. 🙈

Additional examples are found in the distribution's bobcat/process/driver directory. go look, there's more where that came from 🦋

📁 FILES 📁

  • bobcat/process — defines the class interface 🎀

👀 SEE ALSO 👀

bobcat(7), execle(3), exec(3bobcat), coutextractor(3bobcat), cerrextractor(3bobcat), fork(3bobcat), cininserter(3bobcat), proc(3bobcat), sh(1), stdextractor(3bobcat).

(the way this list just keeps going… iykyk, they're all friends of the page 💜)

💀 BUGS 💀

None reported

not a single one?? we love a clean record, that's such a flex ⭐

🌈 BOBCAT PROJECT FILES 🌈

Debian Bobcat project files:

  • libbobcat6: debian package containing the shared library, changelog and copyright note;
  • libbobcat-dev: debian package containing the static library, headers, manual pages, and developer info;

🧚 BOBCAT 🧚

Bobcat is an acronym of Brokken's Own Base Classes And Templates.

(the acronym ate, honestly 👑)

This is free software, distributed under the terms of the GNU General Public License (GPL).

free software, bestie!! share it, remix it, respect the license 🫶

✍️ AUTHOR ✍️

Frank B. Brokken (f.b.brokken@rug.nl).

and that's a wrap on FBB::Process(3bobcat) 💖✨ this page came to you from libbobcat-dev_6.15.01, dated 2005-2026, and it's genuinely giving generational longevity — twenty-plus years of slay. go forth and fork, you've got this 🌸🎀🦋

📦 where this page comes from