Before getting into the details of command interpretation, I thought I'd
give a very simple example of why it's important. Here's an error
that occurs all the time. Let's say you have two files, called
. You want to create a new version of
that has file2
added to the end of it. That's what
is all about, so you give the command:
cat file1 file2 > file1
This looks like it should work. If you've ever tried it, you know it
doesn't; it erases file1
, and then dumps file2
The shell (not cat
) handles standard input and output.
As the shell is processing the command, it sees that you're
redirecting standard output into file1
, so it opens the file for
writing, destroying the data that's already in it.
Later, after it's
finished interpreting the command line, the shell executes cat
as arguments. But file1
(which is empty) and
writes it on standard output (which goes into file1
(which also goes into file1
this point, cat
is finished, so it exits.
are identical, which isn't what
you wanted. But it's what you got.
Some versions of cat
give you a warning message in
cat: input file1 is output
). This might lead you to believe that
was smart and managed to protect you. Sadly, that's
not true. By the time cat
figures out that an input file and an
output file are the same, it's too late: file1
is already gone.
This bit of cat
ty cleverness does have a function, though: it prevents
cat file1 file2 >> file2
from creating infinitely long files.