I ran this command:

python ./manage.py dumpdata partyapp.InvitationTemplate > partyapp_dump.json

To dump data into the partyapp_dump.json file. But all the data just gets printed on the screen and an empty partyapp_dump.json file is created.

Why could this happen? I tested ls > partyapp_dump.json and that worked perfectly.

up vote 40 down vote accepted

With > you only redirect the standard output. Try 2> instead to redirect the error output. Use &> to redirect both.

  • 1
    FYI, &> will only work in Bash 4.0 and iirc recent versions of zsh. For a more portable solution, foo > bar 2&>1. Reference: mywiki.wooledge.org/BashFAQ/014 – Rein Henrichs Apr 14 '11 at 20:40
  • 6
    @Rein Henrichs: That's 2>&1, not 2&>1 – camh Apr 14 '11 at 21:12
  • I remember it with a pneumonic(?) from programming: '2', to('>') the Location('&') Of '1' – hometoast Apr 15 '11 at 11:07
  • 1
    @hometoast: You mean mnemonic? :) Pneumonic means lung... – carlpett Apr 16 '11 at 16:14
  • Hah! Yes. thanks for that. – hometoast Apr 19 '11 at 13:04

Your python app must be writing it's output to the STDERR output channel instead of the normal STDOUT. Using the shell construct > only catches and redirects data written to the output channel, but there are actually several other channels that can be printed to, the most common being the second one, usually used for errors.

You can try trapping STDERR (2nd channel) as well like this:

python ./manage.py dumpdata partyapp.InvitationTemplate > partyapp_dump.json 2>&1

The 2>&1 construct connects the output stream for errors to normal output channel. It is unusual for a program to generate output that you would want to capture on the error channel; usually that would be reserved for debug information not application data. Please use this script with some caution since it is behaving in a non-standard way.

You could also dump the output and error channels to different files like this:

python ./manage.py dumpdata partyapp.InvitationTemplate > partyapp_dump.json 2> error_output.txt

In addition to the already suggested stderr vs stdout output explanation, your application might simply ignore both of these streams and explicitly open "/dev/tty" for its output.

If the noclobber bash option is set, then > redirection will fail (albeit not silently) if the destination file already exists.

For better portability, use cmd >| file to force overwriting any existing file.

If you are lost you can always try to run it with strace to see what processes are doing:

strace -f command
  • 1
    True answer, but not particularly relevant. If the guy didn't now about managing the error stream I don't think he's going to know what to do with the output of an strace. – Caleb Apr 15 '11 at 7:35

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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