Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know cat can do this, but its main purpose is to concatenate rather than just displaying the content.

I also know about less and more, but I'm looking for something simple (not a pager) that just outputs the content of a file to the terminal and it's made specifically for this, if there is such thing.

share|improve this question
Actually 99% of times you use cat is to display files rather than to concatenate anything. – LatinSuD Sep 3 '14 at 15:06
@LatinSuD - 100% of the time - cat concatenates. – mikeserv Sep 3 '14 at 15:07
@mikeserv: It is a matter of what you mean by performing an operation; normal language usage would be to imply it is done at least once. "Printing" an empty string does not involve printing any characters; it would be fair to say it is not printing anything. Now computing a+b+c involves performing 2 additions, and computing a does not involve adding anything. Similarly executing cat f does not involve concatenating anything (even though this is the only thing "concatenating a sequence of one file" could mean). – Marc van Leeuwen Sep 4 '14 at 5:34
@MarcvanLeeuwen - cat never works with one file. It always does in+out - at least two files. – mikeserv Sep 4 '14 at 5:36
@mikeserv: I don't get what you mean by in+out. Sure cat reads a file and writes another file (stream), but that does not mean it is concatenates anything. Should you maybe mean that cat f is actually doing cat - f, that is just not true. – Marc van Leeuwen Sep 4 '14 at 5:41
up vote 13 down vote accepted

I know cat can do this, but its main purpose is to concatenate rather than just displaying the content.

The purpose of cat is exactly that, read a file and output to stdout.

share|improve this answer
But cat --help says "Concatenate FILE(s), or standard input, to standard output". I don't wanna concatenate anything – confused00 Sep 3 '14 at 11:05
Believe it or not, cat is exactly what you're looking for anyway. – Jan Sep 3 '14 at 11:06
No,@confused00, Jan's right. The thing is - the terminal is stdout - you see? do readlink /dev/fd/1 for example - you should get your tty's name in there if running at a standard prompt. So concatenating input to output is what you're asking to do. – mikeserv Sep 3 '14 at 12:00
@mikeserv Yeah, I see your point, I guess I was too fixed on the 'concatenate' meaning. – confused00 Sep 3 '14 at 13:44
The logic is, printing the contents of one file is just a special case of printing the contents of one or more files in sequence. – zwol Sep 4 '14 at 2:03

The most obvious one is cat. But, also have a look at head and tail. There are also other shell utillities to print a file line by line: sed, awk, grep. But those are to alternate the file content or to search inside the file.

I made a few tests to estimate which is the most effective one. I run all trough strace to see which made the least system calls. My file has 1275 lines.

  • awk: 1355 system calls
  • cat: 51 system calls
  • grep: 1337 system calls
  • head: 93 system calls
  • tail: 130 system calls
  • sed: 1378 system calls

As you can see, even if cat was designed to concatenate files, it is the fastest and most effective one. sed, awk and grep printed the file line by line, that why they have more that 1275 system calls.

share|improve this answer
Good idea to count the syscalls! – Jan Sep 3 '14 at 12:32
+1, answer is more accurate (about meaning of cat), more complete (alternatives), and researched (syscalls) – Olivier Dulac Sep 4 '14 at 8:45

Under zsh try


I believe it is the shortest way to print a file. But still it uses 'hidden' cat or more in case if stdout is terminal. However if you really like your cat you can play with it all the time after

share|improve this answer

First, cat writes to the standard output, which is not necessarily a terminal, even if cat was typed as part of a command to an interactive shell. If you really need something to write to the terminal even when the standard output is redirected, that is not so easy (you need to specify which terminal, and there might not even be one if the command is executed from a script), though one could (ab)use the standard error output if the command is merely a part of a pipeline. But since you indicated that cat actually does the job, I suppose you were not asking about such a situation.

If your purpose were to send what is written to the standard output into a pipeline, then using cat would be eligible to the Useless Use of Cat Award, since cat file | pipeline (where pipeline stands for any pipeline) can be done more efficiently as <file pipeline. But again, from your wording I deduce that this was not your intention.

So it is not so clear what you are worrying about. If you find cat too long to type, you can define a one- or two-character alias (there are still a few such names that remain unused in standard Unix). If however you are worrying that cat is spending useless cycles, you shouldn't.

If there were a program null that takes no arguments and just copies standard input to standard output (the neutral object for pipelines), you could do what you want with <file null. There is no such program, though it would be easy to write (a C program with just a one-line main function can do the job), but calling cat without arguments (or cat - if you like to be explicit) does just that.

If there were a nocat program that takes exactly one filename argument, tries to open the file, complains it if cannot, and otherwise proceeds to copy from the file to the standard output, then that would be just what you are asking for. It is only slightly harder to write than null, the main work being opening the file, testing, and possibly complaining (if you are meticulous, you may also want to include a test that there is exacly one argument, and complain otherwise). But again cat, now provided with a single argument, does just that, so there is no need for any nocat program.

Once you succeeded in writing the nocat program, why stop at a single argument? Wrapping the code into a loop for(;*argp!=NULL;++argp) is really no effort at all, adds at most a couple of machine instructions to the binary, and avoids having to complain about a wrong number of arguments (which spares many more instructions). Voilà a primitive version of cat, concatenating files. (To be honest you need to tweak it a little bit so that without arguments it behaves as null.)

Of course in the real cat program, they added a few bells and whistles, because they always do. But the essence is that the "concatenation" aspect of cat costs really no effort at all, neither for the programmer nor for the machine executing it. The fact that cat subsumes null and nocat explains the nonexistence of such programs. Avoid using cat with a single argument if the result goes into a pipeline, but if it is used just for displaying file contents on the terminal, even the page I linked to admits that this is a useful use of cat, so don't hesitate.

You may test that cat is really implemented by a simple loop around a hypthetical nocat functionality, by calling cat with several file names among which one invalid name, not in the first position: rather than complaining right away that this file does not exists, cat first dumps the preceeding valid files, and then complains about the invalid file (at least that is how my cat behaves).

share|improve this answer

POSIX define cat as:


cat - concatenate and print files


cat [-u] [file...]


The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence.

So I think concatenate here means read files in sequence.

share|improve this answer
@MarcvanLeeuwen: Thanks, removed it. – cuonglm Sep 4 '14 at 10:19

I know this is a past tense question. Technically, since printing the contents of a file to stdout is a form of concatenation, cat is semantically appropriate. Don't forget that printf is semantically intended to format and print data. Bash provides mechanisms semantically intended to redirect input and output from files. A combination of these might produce this:

printf '%s' "$(<file.txt)"
share|improve this answer
Apart from being particularly roundabout, the command displayed is not equivalent to cat file.txt, since it will remove any trailing newlines (the $(...) does this). – Marc van Leeuwen Sep 4 '14 at 8:30
+1, nice catch. Did not know that. – James M. Lay Sep 4 '14 at 18:09

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.