No, the pipeline works like this: it first executes the first command and then the second command in your case.

That is, let's have A|B be the command given. Then it is uncertain whether A or B starts first. They might start at exactly the same time if there are multiple CPUs. A pipe can hold an undefined but finite amount of data.

If B tries to read from the pipe, but no data is available, B will wait until the data arrives. If B was reading from a disk, B might have the same problem and need to wait until a disk read finishes. A closer analogy would be reading from a keyboard. There, B would need to wait for a user to type. But in all of these cases, B has started a "read" operation and must wait until it finishes.

If A tries to write to the pipe and the pipe is full, A must wait for some room in the pipe to become free. A could have the same problem if it was writing to a terminal. A terminal has flow control and can moderate the pace of data. In any event, to A, it has started a "write" operation and will wait until the write operation finishes.

A and B are behaving as co-processes, although not all co-processes will be communicating with a pipe. Neither is in full control of the other.

Sortof, the pipeline works like this: it first executes the first command and then the second command in your case.

That is, let's have A|B be the command given. Then it is uncertain whether A or B starts first. They might start at exactly the same time if there are multiple CPUs. A pipe can hold an undefined but finite amount of data.

If B tries to read from the pipe, but no data is available, B will wait until the data arrives. If B was reading from a disk, B might have the same problem and need to wait until a disk read finishes. A closer analogy would be reading from a keyboard. There, B would need to wait for a user to type. But in all of these cases, B has started a "read" operation and must wait until it finishes. But if B is a command such that it needs only partial output of A then after certain point where Bs input level is reached A will be killed by SIGPIPE

If A tries to write to the pipe and the pipe is full, A must wait for some room in the pipe to become free. A could have the same problem if it was writing to a terminal. A terminal has flow control and can moderate the pace of data. In any event, to A, it has started a "write" operation and will wait until the write operation finishes.

A and B are behaving as co-processes, although not all co-processes will be communicating with a pipe. Neither is in full control of the other.

No  , the pipeline works like this. It first executes the first command and then the second command in your case.

that is lets have A|B be the command given then it is uncertain whether A or B starts They might start at the exactly the same time if there are multiple cpu's. A pipe can hold an undefined but finite amount of data.

If B tries to read from the pipe, but no data is available, B will wait until the data arrives. If B was reading from a disk, B might have the same problem and need to wait until a disk read finishes. A closer analogy would be reading from a keyboard. There, B would need to wait for a user to type. But in all of these cases, B has started a "read" operation and must wait until it finishes.

If A tries to write to the pipe, and the pipe is full, A must wait for some room in the pipe to become free. A could have the same problem if A was writing to a terminal. A terminal has flow control and can moderate the pace of data. In any event, to A, it has started a "write" operation and will wait until the write operation finishes.

A and B are behaving as co-processes, although not all co-processes will be communicating with a pipe. Neither is in full control of the other.

No, the pipeline works like this: it first executes the first command and then the second command in your case.

That is, let's have A|B be the command given. Then it is uncertain whether A or B starts first. They might start at exactly the same time if there are multiple CPUs. A pipe can hold an undefined but finite amount of data.

If B tries to read from the pipe, but no data is available, B will wait until the data arrives. If B was reading from a disk, B might have the same problem and need to wait until a disk read finishes. A closer analogy would be reading from a keyboard. There, B would need to wait for a user to type. But in all of these cases, B has started a "read" operation and must wait until it finishes.

If A tries to write to the pipe and the pipe is full, A must wait for some room in the pipe to become free. A could have the same problem if it was writing to a terminal. A terminal has flow control and can moderate the pace of data. In any event, to A, it has started a "write" operation and will wait until the write operation finishes.

A and B are behaving as co-processes, although not all co-processes will be communicating with a pipe. Neither is in full control of the other.