Command to output file content to stdout?

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.

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.

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).