cat foo.txt | less
instead of
 less foo.txt



 cat foo.txt | grep fribble.\*zot
instead of
 grep fribble.\*zot foo.txt



 cat foo.txt | some_command_which_does_not_take_a_filename
instead of
 some_command_which_does_not_take_a_filename < foo.txt
but this last is a matter of preference; some people worry that the latter could destroy the contents of foo.txt with only a single-character typo.

''Yeah, but the first command with a single letter typo can destroy some_command_which does_not_take_a_file_name.  Just try cat foo > some_command when you meant cat foo | some_command sometime when other people depend on some_command and you have write access to it.''

''Only if you specified some_command_etc with a full pathname.''

Pipes in fact tend to be monstrously inefficient, but the mode (StatisticalFunction) development machine has enough CPU time that nobody would ever, ever notice, except when it's playing QuakeGame.

''OTOH...  If you don't know how to avoid writing '''rm -rf /''' when you don't mean it, don't use shell.  ;->''


If I'm developing a complex pipeline and the input file is long, I'll often start the pipe with head

 head long_file | monstrous catenation | of | awk | and | cut and |sed

When the answer looks right, I just replace the head with cat.  If efficiency matters, why are you using the shell anyway?

''In a related vein, I often develop a pipeline with echo instead of rm. Seems reasonable. -- StephanHouben''