A Bash coprocess is an asynchronous background process spawned by the shell with a bidirectional inter-process communication (IPC) channel automatically established. Initiated using theDocumentation Index
Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt
Use this file to discover all available pages before exploring further.
coproc reserved word, it connects the standard input (stdin) and standard output (stdout) of the executed command to file descriptors accessible within the parent shell’s execution context.
Syntax
A coprocess can be declared anonymously (using the default name) or with an explicit identifier.{ ...; }) must be used. If a simple command is provided (e.g., coproc NAME echo "data"), Bash parses the intended NAME as the command itself and the subsequent words as its arguments.
State and File Descriptors
When a coprocess is invoked, Bash allocates a two-way pipe and populates specific variables in the parent shell to manage the IPC state. If no explicitNAME is provided, Bash defaults to the identifier COPROC.
- File Descriptor Array (
NAME): Bash creates an indexed array containing two file descriptors.${NAME[0]}: Connected to the standard output of the coprocess. The parent shell reads from this descriptor.${NAME[1]}: Connected to the standard input of the coprocess. The parent shell writes to this descriptor.
- Process ID (
NAME_PID): Bash stores the Process ID (PID) of the spawned background process in a variable suffixed with_PID.
I/O Operations and Asynchronous Hazards
Interaction with the coprocess relies on standard Bash file descriptor redirection. Writing to the coprocess: To send data to the coprocess, redirect standard output to the file descriptor stored in index 1.NAME array. If the parent shell attempts to evaluate an I/O redirection like >&"${NAME[1]}" after the background process has finished and the array has been unset, the expansion yields an empty string. This randomly results in an ambiguous redirect error if the coprocess finishes faster than the parent shell expects. Robust implementations must verify the existence of the file descriptor or the PID before attempting I/O.
Lifecycle and Termination
The coprocess lifecycle is tied to the execution of its underlying command and the state of its file descriptors.-
EOF Handling: To signal the coprocess that no more input will be sent, the parent shell must explicitly close the write file descriptor. This sends an End-Of-File (EOF) to the coprocess’s stdin. Because the
{varname}>&-syntax requires a simple shell identifier and does not support array elements, the file descriptor must be closed dynamically. Critical Safety Pitfall: Due to the asynchronous cleanup mentioned above, if the coprocess terminates early, theNAMEarray is unset. If you useeval "exec ${NAME[1]}>&-", the empty expansion results inexec >&-, which silently closes the parent shell’s own standard output. This must be mitigated by using parameter expansion modifiers (like:?) or explicit checks:
- Automatic Cleanup: When the coprocess terminates, Bash automatically closes both file descriptors and unsets the
NAMEarray andNAME_PIDvariable from the parent shell’s environment. - Concurrency Limit: Bash officially supports only one active coprocess at a time. Attempting to spawn a second coprocess before the first terminates will generate a warning (
warning: execute_coproc: coproc [PID:NAME] already exists) and may result in orphaned file descriptors.
The Buffering Caveat
Because the IPC channel relies on standard pipes, the standard I/O streams of the command executing inside the coprocess are subject to block buffering by the C library (libc) when not connected to a pseudo-terminal (PTY). If the coprocess command does not explicitly flush its output buffers, the parent shell will hang indefinitely on aread operation, resulting in a deadlock. This mechanical limitation requires the internal command to either natively support line-buffering or be wrapped in utilities that manipulate stream buffering behavior (e.g., stdbuf -i0 -o0).
Master Bash with Deep Grasping Methodology!Learn More





