The Unix Philosophy: Pipes and Redirection

In one line

Each Unix tool does ONE thing well, and the pipe (|) is what lets you chain them into a custom pipeline — this single idea is arguably the most powerful concept in this entire course.

0/4 · 0%

Think of it like this

An assembly line, where each station does exactly one small job — attach a part, tighten a bolt, apply a label — and the OUTPUT of one station becomes the INPUT of the next. The pipe operator | does exactly this for commands: the output of the command on the left becomes the input of the command on the right.

Key ideas

01
The Unix philosophy, stated plainly: write programs that do one thing well, that work together, and that handle plain TEXT as a universal interface — since text is the one format every tool can read and write, ANY two tools can be combined, even ones written decades apart by people who never coordinated with each other.
02
command1 | command2 pipes command1's OUTPUT directly into command2's INPUT, without ever writing an intermediate file to disk — ls -l | grep '.txt' lists files, then filters that listing down to only lines mentioning '.txt', all in one line with no temp file involved anywhere.
03
Redirection (>, >>, from Phase 1) sends output to a FILE; piping (|) sends output to ANOTHER COMMAND instead — related concepts, different destinations. You can combine both: command1 | command2 > output.txt pipes through command2, then saves the final result to a file.
04
< redirects a FILE's contents IN as a command's input, the mirror image of > — sort < names.txt reads from the file instead of from your keyboard, though in practice sort names.txt (passing it as an argument) is more common for tools that accept a filename argument directly.
05
Pipelines can chain as many commands as you like: cat access.log | grep '404' | wc -l reads a log file, filters to only lines containing '404', then counts how many lines remain — three tiny, unrelated tools, combined into a genuinely useful one-liner none of them could do alone.

Code & diagrams

PipeFlowdiagram

Each command's stdout becomes the next command's stdin — nothing is ever written to disk in between.

Rendering diagram…

pipes-basics.shmarkdown

Each pipeline chains small, single-purpose tools — try each step separately first, then chained.

# Each command alone
ls -l /etc
grep "conf"
wc -l

# Now chained: list /etc, filter to lines containing "conf", count them
ls -l /etc | grep "conf" | wc -l

# Redirection vs piping, combined in one line
cat /etc/passwd | cut -d: -f1 | sort > all-usernames.txt
cat all-usernames.txt

# A realistic log-triage one-liner
# cat app.log | grep ERROR | wc -l

Explain it without notes

Why is 'do one thing well' combined with piping considered more powerful than building one giant tool that does everything?

What's the actual difference between redirection (>) and piping (|), given that both involve sending output somewhere?

Practice

Build a three-stage pipeline of your own from tools you already know (Phase 1's cat/grep count as valid building blocks) and describe in one sentence what each stage contributes.

Take any pipeline you build and add a final > results.txt to save the end result to a file, then confirm the intermediate stages never created any files themselves.

Trade-offs

↔
Long pipelines are extremely powerful but can become genuinely hard to read past 4-5 stages chained together — for anything you'll need to revisit or explain to someone else later, a short shell script (Phase 6) with named intermediate steps is often the better long-term choice over an ever-growing one-liner.

Done when you can

I understand the Unix philosophy: small tools, one job each, connected by pipes.
I can build a multi-stage pipeline using | to solve a real, concrete task.
I know the difference between redirecting to a file (>) and piping to another command (|).