Pipes are a great idea, but are severely hampered by the many edge cases around escaping, quoting, and, my pet peeve, error handling. By default, in modern shells, this will actually succeed with no error:<p><pre><code> $ alias fail=exit 1
$ find / | fail | wc -l; echo $?
0
0
</code></pre>
You can turn on the "pipefail" option to remedy this:<p><pre><code> $ set -o pipefail
$ find / | fail | wc -l; echo $?
0
1
</code></pre>
Most scripts don't, because the option makes everything much stricter, and requires more error handling.<p>Of course, a lot of scripts also forget to enable the similarly strict "errexit" (-e) and "nounset" options (-u), which are also important in modern scripting.<p>There's another error that hardly anyone bothers to handle correctly:<p><pre><code> x=$(find / | fail | wc -l)
</code></pre>
This sets x to "" because the command failed. The only way to test if this succeeded is to check $?, or use an if statement around it:<p><pre><code> if ! x=$(find / | fail | wc -l); then
echo "Fail!" >&2
exit 1
fi
</code></pre>
I don't think I've seen a script ever bother do this.<p>Of course, if you also want the error message from the command. If you want that, you have to start using name pipes or temporary files, with the attendant cleanup. Shell scripting is suddenly much more complicated, and the resulting scripts become much less fun to write.<p>And that's why shell scripts are so brittle.