I was working through a tutorial and saw use of both cat myfile.txt
and cat < myfile.txt
. Is there a difference between these two sequences of commands? It seems both print the contents of a file to the shell.

- 333,661

- 833
-
3Related: When should I use input redirection? (and (remotely) Should I care about unnecessary cats?) – Stéphane Chazelas Feb 02 '16 at 13:10
-
See also https://askubuntu.com/a/1192464/295286 for difference on what syscalls are executed when these two commands are called – Sergiy Kolodyazhnyy Apr 30 '20 at 02:35
5 Answers
In the first case, cat
opens the file, and in the second case, the shell opens the file, passing it as cat
's standard input.
Technically, they could have different effects. For instance, it would be possible to have a shell implementation that was more (or less) privileged than the cat
program. For that scenario, one might fail to open the file, while the other could.
That is not the usual scenario, but mentioned to point out that the shell and cat
are not the same program.

- 76,765
-
89Yes, and for example you can do
sudo cat myfile.txt
. Butsudo cat < myfile.txt
will not work if you don't have privileges to read the file. – zuazo Jan 31 '16 at 22:07 -
2Note that
ksh93
hascat
builtin (not enabled by default unless you have/opt/ast/bin
early in your$PATH
though). – Stéphane Chazelas Feb 02 '16 at 13:18 -
2Some programs behave differently depending on whether they get a filename argument or stdin. For instance,
wc
will print the filename before the counts when given an argument. – Barmar Feb 03 '16 at 19:51
There is no major visible difference in your test case. The most obvious one would be the error message you get if there is no file named myfile.txt
in the current directory, or if you are not allowed to read it.
In the former case, cat
will complain and in the latter case, your shell will, clearly showing which process is trying to open the file, cat
in the former one and the shell in the latter one.
$ cat myfile.txt
cat: myfile.txt: No such file or directory
$ cat < myfile.txt
ksh93: myfile.txt: cannot open [No such file or directory]
In a more general case, a major difference is using redirections cannot be used to print the content of more than one file, which is after all the original purpose of the cat
(i.e. catenate) command. Note that the shell will anyway try to open all files passed as redirected input, but only actually pass the last one to cat
unless you use zsh
and its multios
"zshism".
$ echo one > one
$ echo two > two
$ cat one two # cat opens one, shows one, opens two, shows two
one
two
$ cat < one < two # sh opens one then opens two, cat shows stdin (two)
two
$ rm one two
$ echo one > one
$ cat one two # cat opens and shows one, fails to open two
one
cat: two: No such file or directory
$ cat < one < two # the shell opens one then opens two, fails and
# displays an error message, cat gets nothing on stdin
# so shows nothing
ksh93: two: cannot open [No such file or directory]
On a standard system, the shell and cat
have no difference in file access rights so both will succeed of fail equally. Using sudo
to raise cat
's privileges will make a big difference in behavior, as Thomas Dickey reply and attached comments already suggested.

- 61,204
-
5Out of curiosity, do you really use use
ksh
of your own volition, and if so... why? – cat Feb 01 '16 at 01:51 -
1@cat - that question is obviously based in ignorance. build it yourself and see. – mikeserv Feb 01 '16 at 01:57
-
2@mikeserv that was intended to be flippant, not seriously rude, but fair enough, i suppose – cat Feb 01 '16 at 02:01
-
2@cat - i didnt suppose otherwise. ignorance is not a thing to be ashamed of - it is only a lack of knowledge. if you dont understand why someone might choose to use ksh93, then i can only assume it is because you've never used it. so i recommend you do. its worth trying, to be sure. and believe me when i tell you, that, compared to
bash
,ksh93
is far and away the better shell. it's the shell, almost. – mikeserv Feb 01 '16 at 02:05 -
On Solaris 11, /bin/sh is actually ksh93 though it says sh in the error message. – Bjorn Munch Feb 01 '16 at 07:10
-
1@cat Yes, ksh93 is my personal choice whenever possible. What makes you think that might not have been the case? – jlliagre Feb 01 '16 at 08:40
-
@BjornMunch
/bin/sh
is a link toksh93
on Solaris 11. It is quite a common practice to create such links to whatever shell is selected by the OS editor to be the default one, e.g.bash
on Red Hat,dash
on Ubuntu, andksh88
on many commercial Unix. To display error messages, some of these shells will pick the name they have been called with, that explains the/bin/sh
you got with Solaris 11. – jlliagre Feb 01 '16 at 11:05 -
5As @mikeserv pointed out elsewhere,
cat < file1 > file2
has a very different effect fromcat file1 > file2
in the case wherefile1
is unreadable or nonexistent. (The latter form truncatesfile2
; the former will not.) – Wildcard Feb 01 '16 at 18:02 -
@Wildcard - its better fleshed here. This question is practically a duplicate, really. I didnt mention it before because it gets hard to find those among 1500 other answers... – mikeserv Feb 01 '16 at 18:32
-
1@Wildcard and mikeserv thanks for pointing out the difference between
cat < file1 > file2
andcat file1 > file2
. I just wish I had known that years ago. – Josh Rumbut Feb 01 '16 at 18:55
cat myfile.txt
reads the file myfile.txt
then prints it to the standard output.
cat < myfile.txt
here cat
isn't given any file(s) to open, so -like many Unix commands do- reads the data from the standard input, which is directed there from file.txt
by the shell, and prints to standard output.

- 18,253

- 315
- 1
- 7
@Thomas Dickey's answer is brilliant.
I just want to add some obvious facts about the case of reading several files (loosely related to your question, but still):
cat <file1 <file2 <file3
will read only file3, at least in bash. (Actually, it depends on shell, but most shells will dup every specified file to stdin, which causes the last one to effect.)cat file1 file2 file3
will read all the specified files sequentially (actually cat is shortened form of the word concatenate).cat file1 file2 file3 <file4 <file5 <file6
will read only file1, file2, file3 (as cat ignores stdin when filename arguments are passed).cat file1 file2 - file3 <file4 <file5 <file6
will read file1, file2, file6, file3 (as hyphen forces cat not to ignore stdin).
And about errors. In case of inability to open some of files specified as arguments (without <
), cat will skip failed files (with outputting relevant message to stderr), but still read other files. In case of inability to open at least one of files specified as redirections (with <
), shell won't even start cat (this occurs even for redirections actually not used by cat). In both cases erroneous exit code will be returned.
-
1Note that in your first example
cat
will nevertheless openfile1
andfile2
, same withfile4
andfile5
in your third example. It will only showfile3
, resp.file6
contents if these previous open instructions succeed. – jlliagre Feb 02 '16 at 19:36 -
@jlliagre, thanks, I didn't know that. Strace obviously proved your correctness. I corrected parenthesised text for cases 1 and 3a. – sasha Feb 03 '16 at 00:40
We can use another command to notice the difference between:
wc –w food2.txt
Possible output:
6 food2.txt
The command tells the file name since it knows it (passed as an argument).
wc –w < food2.txt
Possible output:
6
The standard input is redirected to file food2.txt
without the command knowing about the file's name.

- 333,661