Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was experimenting today with some append operations and, in my curiosity, ran this (where file1.txt was non-empty and file2.txt was empty):

$ cat file1.txt >> file2.txt >> file1.txt

When I saw it taking a while, I hit Ctrl+C to end it. By then, file1.txt was hundreds of MB in size.

Switching the file names doesn't produce the same effect; only when the files are in this order does the infinite redirection happen. What exactly is going on that causes this?

share|improve this question
up vote 21 down vote accepted

You cannot tell cat to use multiple standard out that way, the last redirection takes precedence so

cat file1.txt >> file2.txt >> file1.txt

is equivalent to

>> file2.txt ; cat file1.txt >> file1.txt

which obviously quickly fills the file system, given the fact the source file being the destination too grows indefinitely as long as file1.txt is large enough not to be read at once.

Most modern cat implementations should detect the recursivity and abort:

Solaris cat:

cat: input/output files 'file1.txt' identical

Gnu cat:

cat: file1.txt: input file is output file

They can be fooled with something like:

cat < file1.txt | cat | cat  >> file2.txt >> file1.txt

A nice not so useless use of cats ...

share|improve this answer
That's a lot of cats, meow. – slm Sep 10 '13 at 23:54
You made my head spin but you answered my question! – Matt Sep 11 '13 at 0:11
And when I asked about this on Google+ (didn't get an answer), it automatically tagged my post with #Cat and #Caturday – Matt Sep 11 '13 at 2:54

I wasn't able to reproduce this in a Bash shell:

# non-empty file1
$ echo 1 > file1.txt

$ cat file1.txt >> file2.txt >> file1.txt 
cat: file1.txt: input file is output file

1 file gets created with 0 length but then I get the above message:

$ ls -l
total 4
-rw-rw-r-- 1 saml saml   2 Sep 10 19:35 file1.txt
-rw-rw-r-- 1 saml saml   0 Sep 10 19:35 file2.txt

Based on @jlliagre's answer I'm not sure why I'm getting the 2 files. It may be dependent on the cat implementation.


@jlliagre updated his answer to show this code which he states as equivalent:

>> file2.txt ; cat file1.txt >> file1.txt

So now I know why I'm getting the empty file2.txt. This notation is legal:

>> file2.txt

And will create an empty file.

share|improve this answer
Try again with file1.txt starting out non-empty. – Gilles Sep 10 '13 at 23:46
@Gilles - I just re-read that and noticed it, should I see something different, I still get the error? Or are you just saying that b/c the example in my answer is wrong? I fixed the answer BTW. – slm Sep 10 '13 at 23:49
@Gilles - that was your downvote, no? Is it just for something specific or lack of value of the answer? – slm Sep 10 '13 at 23:51
Not sure why your answer was voted down, +1 for experiencing before answering, something I didn't do myself ... – jlliagre Sep 10 '13 at 23:54
+1; thanks for your experimentation! I'm starting to understand redirects and cat behavior better. – Matt Sep 11 '13 at 0:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.