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