Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

A lot of command-line utilities can take their input either from a pipe or as a filename argument. For long shell scripts, I find starting the chain off with a cat makes it more readable, especially if the first command would need multi-line arguments.


sed s/bla/blaha/ data \
| grep blah \
| grep -n babla


cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

Is the latter method less efficient? If so, is the difference enough to care about if the script is run, say, once a second? The difference in readability is not huge.

share|improve this question
I spend way more time watching people attack each other about useless cat usage on this site than my system does actually starting the cat processes –  Michael Mrozek Jul 8 '11 at 14:23
@Michael: 100% agree. Heck it took me more time to link to the old usenet award once than my computer will ever waste instantiating cat. However I think the bigger question here is code readability which often is a priority over performance. When faster can actually be written prettier, why not? Pointing out the issue with cat usually leads to the user having a better understanding of pipelines and processes in general. It's worth the effort so they write comprehensible code next time around. –  Caleb Jul 8 '11 at 15:03
I actually have another reason I don't like the first form - if you want to add another command at the beginning of the pipeline, you have to move the argument too, so the editing is more annoying. (Of course, this doesn't mean you have to use cat; Caleb's point about using functions and redirection solves that as well.) –  Jefromi Jul 17 '11 at 7:15
Related: Remove useless-uses-of-cat or not?  (Meta) –  G-Man Aug 26 at 6:40

4 Answers 4

up vote 29 down vote accepted

The "definitive" answer is of course brought to you by The Useless Use of cat Award.

The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process.

Instantiating cat just so your code reads differently makes for just one more process and one more set of input/output streams that are not needed. Typically the real hold-up in your scripts is going to be inefficient loops and actuall processing. On most modern systems, one extra cat is not going to kill your performance, but there is almost always another way to write your code.

Most programs, as you note, are able to accept an argument for the input file. However, there is always the shell builtin < that can be used wherever a STDIN stream is expected which will save you one process by doing the work in the shell process that is already running.

You can even get creative with WHERE you write it. Normally it would be placed at the end of a command before you specify any output redirects or pipes like this:

sed s/blah/blaha/ < data | pipe

But it doesn't have to be that way. It can even come first. For instance your example code could be written like this:

< data \
    sed s/bla/blaha/ |
    grep blah \
    grep -n babla

If script readability is your concern and your code is messy enough that adding a line for cat is expected to make it easier to follow, there are other ways to clean up your code. One that I use a lot that helps make scripts easiy to figure out later is breaking up pipes into logical sets and saving them in functions. The script code then becomes very natural, and any one part of the pipline is easier to debug.

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

fix_blahs < data

You could then continue with fix_blahs < data | fix_frogs | reorder | format_for_sql. A pipleline that reads like that is really easy to follow, and the individual components can be debuged easily in their respective functions.

share|improve this answer
I didn't know that <file could come before the command. This solves all of my problems! –  user4518 Jul 8 '11 at 13:43
@Tim: Bash and Zsh both support that, although I think it's ugly. When I'm worried about my code being pretty and maintainable I usually use functions to clean it up. See my last edit. –  Caleb Jul 8 '11 at 13:55
@Tim <file can come anywhere on the command line: <file grep needle or grep <file needle or grep needle <file. The exception is complex commands such as loops and groupings; there the redirection must come after the closing done/}/)/etc. @Caleb This holds in all Bourne/POSIX shells. And I disagree that it's ugly. –  Gilles Jul 8 '11 at 21:43
@Gilles, in bash you can replace $(cat /some/file) with $(< /some/file), which does the same thing but avoids spawning a process. –  cjm Jul 10 '11 at 20:27
Just to confirm that $(< /some/file) is of limited portability. It does work in bash, but not BusyBox ash, for example, or FreeBSD sh. Probably doesn't work in dash either, since those last three shells are all close cousins. –  dubiousjim Nov 14 '12 at 19:24

Putting <file on the end of a pipeline is less readable than having cat file at the start. Natural English reads from left to right.

Putting <file a the start of the pipeline is also less readable than cat, I would say. A word is more readable than a symbol, especially a symbol which seems to point the wrong way.

Using cat preserves the command | command | command format.

share|improve this answer
I agree, using < once makes code less readable, since it destroys the syntax consistency of a multipipeline. –  A.Danischewski Mar 29 at 19:17

One thing that the other answers here don't seem to have directly addressed is that using cat like this isn't "useless" in the sense that "an extraneous cat process is spawned that does no work"; it's useless in the sense that "a cat process is spawned that does only unnecessary work".

In the case of these two:

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

the shell starts a sed process that reads from somefile or stdin (respectively) and then does some processing - it reads up until it hits a newline, replaces the first 'foo' (if any) on that line with 'bar', then prints that line to stdout and loops.

In the case of:

cat somefile | sed 's/foo/bar/'

The shell spawns a cat process and a sed process, and wires cat's stdout to sed's stdin. The cat process reads a several kilo- or maybe mega- byte chunk out of the file, then writes that out to its stdout, where the sed sommand picks up from there as in the second example above. While sed is processing that chunk, cat is reading another chunk and writing it to its stdout for sed to work on next.

In other words, the extra work necessitated by adding the cat command isn't just the extra work of spawning an extra cat process, it's also the extra work of reading and writing the bytes of the file twice instead of once. Now, practically speaking and on modern systems, that doesn't make a huge difference - it may make your system do a few microseconds of unnecessary work. But if it's for a script that you plan on distributing, potentially to people using it on machines that are already underpowered, a few microseconds can add up over a lot of iterations.

share|improve this answer

Here's a summary of some of the drawbacks of:

cat $file | cmd


< $file cmd
  • First, a note: there are (intentionally for the purpose of the discussion) missing double quotes around $file above. In the case of cat, that's always a problem except for zsh; in the case of the redirection, that's only a problem for bash or for some other shells only when interactive (not in scripts).
  • The most often cited drawback is the extra process being spawned. Note that if cmd is builtin, that's even 2 processes in some shells like bash.
  • Still on the performance front, except in shells where cat is builtin, that also an extra command being executed (and of course loaded, and initialised (and the libraries it's linked to as well)).
  • Still on the performance front, for large files, that means the system will have to alternately schedule the cat and cmd processes and constantly fill up and empty the pipe buffer. Even if cmd does 1GB large read() system calls at a time, control will have to go back and forth between cat and cmd because a pipe can't hold more than a few kilobytes of data at a time.
  • Some cmds (like wc -c) can do some optimisations when their stdin is a regular file which they can't do with cat | cmd as their stdin is just a pipe then. With cat and a pipe, it also means they cannot seek() within the file. For commands like tac or tail, that makes a huge difference in performance as that means that with cat they need to store the whole input in memory.
  • The cat $file, and even its more correct version cat -- "$file" won't work properly for some specific file names like - (or --help or anything starting with - if you forget the --). If one insists on using cat, he should probably use cat < "$file" | cmd instead for reliability.
  • If $file cannot be open for reading (access denied, doesn't exist...), < "$file" cmd will report a consistent error message (by the shell) and not run cmd, while cat $file | cmd will still run cmd but with its stdin looking like it's an empty file. That also means that in things like < file cmd > file2, file2 is not clobbered if file can't be opened.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.