Connecting the Dots
Imagine a factory assembly line. The first station stamps a metal blank, passes it to the second station which drills holes, which passes it to the third station which paints it. No station stores the intermediate product — it flows directly to the next. The Unix pipe works exactly this way.
The Unix philosophy is: "Write programs that do one thing and do it well. Write programs to work together." The primary mechanism for that cooperation is the pipe, represented by the vertical bar character: |.
A pipe takes the Standard Output (STDOUT) of the command on the left and feeds it directly as the Standard Input (STDIN) to the command on the right. Critically, this happens in memory — no temporary files are created, and both commands run concurrently. The left command writes data into a kernel buffer; the right command reads from it. Chaining several pipes together — filtering a listing down to matching lines, then sorting those lines, then taking the top few — composes small single-purpose tools into a pipeline that does something none of them could do alone. Each command in the chain is a filter: it receives data, transforms it, and passes it on.
Interviewers sometimes ask: "What is the difference between a pipe and a subshell?" A pipe connects two processes via a kernel buffer — both run concurrently in separate subshells. A common gotcha: variables set inside a piped command are lost after the pipe because each side runs in its own subshell. For example, echo "hello" | read VAR; echo $VAR will print nothing, because read ran in a subshell. This surprises many candidates.