Com > você só redireciona a saída padrão. Tente 2 > para redirecionar a saída do erro. Use & > para redirecionar os dois.
Eu executei este comando:
python ./manage.py dumpdata partyapp.InvitationTemplate > partyapp_dump.json
Para despejar dados no arquivo partyapp_dump.json . Mas todos os dados são impressos na tela e um arquivo partyapp_dump.json vazio é criado.
Por que isso aconteceu? Eu testei ls > partyapp_dump.json e isso funcionou perfeitamente.
Seu aplicativo python deve estar gravando sua saída para o canal de saída STDERR em vez do STDOUT normal. Usar a construção de shell > apenas captura e redireciona dados gravados no canal de saída, mas na verdade existem vários outros canais que podem ser impressos, sendo o mais comum o segundo, geralmente usado para erros.
Você pode tentar capturar o STDERR (segundo canal) assim:
python ./manage.py dumpdata partyapp.InvitationTemplate > partyapp_dump.json 2>&1
A construção 2>&1 conecta o fluxo de saída para erros ao canal de saída normal. É incomum que um programa gere uma saída que você gostaria de capturar no canal de erro; geralmente, isso seria reservado para informações de depuração que não fossem dados do aplicativo. Por favor, use este script com alguma cautela , pois ele está se comportando de maneira não padronizada.
Você também pode enviar os canais de saída e erro para arquivos diferentes como este:
python ./manage.py dumpdata partyapp.InvitationTemplate > partyapp_dump.json 2> error_output.txt
Além da explicação de saída stderr vs stdout já sugerida, seu aplicativo pode simplesmente ignorar ambos os fluxos e abrir explicitamente "/ dev / tty" para sua saída.
Se a opção noclobber bash estiver definida, então > o redirecionamento falhará (embora não silenciosamente) se o arquivo de destino já existir.
Para melhor portabilidade, use cmd >| file para forçar a substituição de qualquer arquivo existente.
Se você estiver perdido, sempre poderá tentar executá-lo com strace para ver o que os processos estão fazendo:
strace -f command