In this page from The Design and Implementation of the 4.4BSD Operating System, it is said that:

A major difference between pipes and sockets is that pipes require a common parent process to set up the communications channel

However, if I record correctly, the only way to create a new process is to fork an existing one. So I can’t really see how 2 processes could not have a common ancestor. Am I then right to think that any pair of processes can be piped to each other?

  • 1
    If your question is really about a "common ancestor" that's not what your quote says. A parent is an ancestor, but not all ancestors are parents. – msw May 12 '13 at 12:41
  • have a look at ps auxf for an idea about process ancestors. – michas May 12 '13 at 12:45
  • @msw do you mean that the 2 processes need to have the same direct parent? being cousin (i.e. having a common grandparent) is not enough? – qdii May 12 '13 at 12:47

Am I then right to think that any pair of processes can be piped to each other?

Not really.

The pipes need to be set up by the parent process before the child or children are forked. Once the child process is forked, its file descriptors cannot be manipulated "from the outside" (ignoring things like debuggers), the parent (or any other process) can't do the "set up the comms. channel" part after the fact.

So if you take two random processes that are already running, you can't set up a pipe between them directly. You need to use some form of socket (or another IPC mechanism) to get them to communicate. (But note that some operating systems, FreeBSD among them, allow you to send file descriptors on Unix-domain sockets.)


That sentence isn't very clear. First, parent should be ancestor, as the process setting up the pipe can be a parent, or a grandparent, or a grand-grand-…-grandparent, or one of the communicating processes. Second, the sentence doesn't mean “if you want a pipe, there must exist a common ancestor process”, but “if you want a pipe, a common ancestor process must set it up”.

Under the hood, a process establishes a pipe with itself. The pipe is a file descriptor like any other, or more precisely a pair of file descriptors, one for each end. The process that created the pipe can use it immediately to send data to itself, although this is rarely useful (though a self-pipe does have its use).

A typical idiom is for a process to set up a pipe, then fork a child process, and close one end of the pipe in the parent and the other end of the pipe in the child. This lets the parent and the child process communicate in one direction. If the processes need bidirectional communication, they need two pipes (except on some unix variants where pipes are bidirectional).

The pipes are inherited in turn by any children, so the process that created the pipe may not be involved in the communication. For example, a pipe in a shell created between two external commands such as ls | rot13 involves the following steps:

  • The shell creates a pipe.
  • The shell forks a process. The child closes the read end of the pipe and calls execve on ls.
  • The shell forks a process. The child closes the write end of the pipe and calls execve on rot13.
  • The shell closes both ends of the pipe and waits for both subprocesses to exit.

If two existing processes want to communicate with each other, they can use a named pipe. (Well, there's also file descriptor passing, but it's not for the faint of heart.)


The shell of the pipeline is the common parent which sets up a communication channel between the several members of the pipeline.

Any process can be piped to any other. The only processes that can usefully be piped together are "filters" that read from stdin and write to stdout.

For example, if you issue the command

$ tail -f /etc/motd | tail -f | cat > /dev/null

ps -eaH will show that the cat and its two tails are children of the invoking shell:

 1675 pts/0    00:00:00     bash
 2483 pts/0    00:00:00       tail
 2484 pts/0    00:00:00       tail
 2485 pts/0    00:00:00       cat

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.