# Pipes and the Unix Philosophy

DevFeed: [Pipes and the Unix Philosophy](<https://devfeed.tech/articles/for-the-love-of-pipes-35165.md>)

Original publisher: [Read original article](<https://blog.jessfraz.com/post/for-the-love-of-pipes/>)

Published: 2019-01-21T15:09:26Z

Content type: opinion

Language: en

Sources: [Jessie Frazelle](<https://devfeed.tech/sources/jessie-frazelle.md>)

Topics: [Unix](<https://devfeed.tech/topics/unix.md>), [Shell](<https://devfeed.tech/topics/shell.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>)

## AI overview

An opinion piece explaining shell pipes, which connect one program's output to another program's input. It relates pipes to the Unix philosophy of small, composable tools.

## Source excerpt

My top used shell command is |. This is called a pipe. In brief, the | allows for the output of one program (on the left) to become the input of another program (on the right). It is a way of connecting two commands together. For example, if I were to run the following: echo "hello" I get the output hello. But if I run: echo "hello" | figlet The figlet program, changes the letters in hello to look all bubbly and cartoony. This is a really blunt way of describing something that, in my opinion, is brilliant software design, but I will get into that in a second. Let's go back to the origin of pipes. According to doc.cat-v.org/unix/pipes/, the origin of pipes came long before Unix. Pipes can be traced back to this note from Doug McIlroy in 1964: - 10 - Summary--what's most important. To put my strongest concerns into a nutshell: 1. We should have some ways of coupling programs like garden hose--screw in another segment when it becomes when it becomes necessary to massage data in another way. This is the way of IO also. 2. Our loader should be able to do link-loading and controlled establishment. 3. Our library filing scheme should allow for rather general indexing, responsibility, generations, data path switching. 4. It should be possible to get private system components (all routines are system components) for buggering around with. M. D. McIlroy October 11, 1964 The Unix philosophy is documented by Doug McIlroy as: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. Use tools in preference to unskilled help to ligh