Command to output file content to stdout?

Question

I know cat can do this, but its main purpose is to concatenate rather than just to display 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.

Answer 1

The most obvious one is cat. But also have a look at head and tail.

There are other shell utilities to print a file line by line: sed, awk, grep. But those are meant to manipulate the file content or to search inside the file.

I made a few tests to estimate which is the most effective one. I ran all trough strace to see which made the fewest 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's why they have more that 1275 system calls.

Answer 2

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.

Answer 3

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

Answer 4

Under zsh try

<file

I believe it is the shortest way to print a file. It uses 'hidden' cat (or more if stdout is a terminal), but the command used for printing is controlled by READNULLCMD variable which you can safely overwrite directly by command name or even by some function. For example to print files with line numbering:

numcat() { nl -s'> ' -w2 - }
READNULLCMD=numcat
<file

Answer 5

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 also provides syntax to redirect input and output from files. A combination of these might produce this:

printf '%s' "$(<file.txt)"

Answer 6

POSIX define cat as:

NAME

cat - concatenate and print files

SYNOPSIS

cat [-u] [file...]

DESCRIPTION

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.

Answer 7

Just as a demonstration, you can do

cp foo /dev/stdout

Answer 8

Using bash builtins and avoiding subprocess creation:

{ while IFS='' read -rd '' _bcat_; do printf '%s\0' "${_bcat_}"; done; printf '%s' "${_bcat_}"; unset _bcat_; } <'/path/to/file'

IFS will be applied only to read command, so do not worry about your global IFS changes.

Loop required to handle null characters (thanks to Stéphane Chazelas ).

This way is not suitable for big files because file content read to the variable (so memory) first. BTW I've tried to print 39M text file this way and bash memory usage did not exceed 5M, so not sure about this case.

It also damn slow and CPU inefficient: for the same 39M file it took ~3 minutes with 100% usage of single core.

For big files or binaries better to use cat '/path/to/file' or even dd if='/path/to/file' bs=1M if possible.