2

I have decided to try snakefood to help with a refactoring to check the imports. It keeps dumping output on the screen and ">" does not send it to a file, it just creates an empty file.

I had to unfortunately create a virtualenv with Python 2.7 as it probably does not work properly in Python 3. Still, it can probably check a Python 2 project, even though it is written in Python 2. Am using a Mac, but it seems to use similar commands to Linux on the command line.

I did

pip install six
pip install graphviz
pip install snakefood

once the Python 2 environment was activated.

Then if I type

$ sfood-checker path/to/folder

..it dumps a huge amount of text on the screen, but

$ sfood-checker path/to/folder > check.txt

..only creates an empty file. Any idea what is wrong, how to fix it? Would like to carefully go through the file in sublime.

n00dl3
  • 21,213
  • 7
  • 66
  • 76
cardamom
  • 6,873
  • 11
  • 48
  • 102
  • 3
    Probably because the messages are printed to `std_err` instead of `std_out`. Btw, this is more of a bash/unix question than python. – Arne Feb 13 '18 at 14:28

1 Answers1

8

You are redirecting stdout, but your program is writing to stderr. The fix is to redirect stderr:

$ sfood-checker path/to/folder 2> check.txt

Or redirect both stdout and stderr:

$ sfood-checker path/to/folder &> check.txt

Background: when processes are initially created, they generally always have three initial file descriptors already opened for them:

  • 0, stdin, "Standard Input", a read-only stream
  • 1, stdout, "Standard Output", a write-only stream
  • 2, stderr, "Standard Error", a write-only stream

There is precisely zero difference between stdout and stderr, other than convention and the file descriptor number. By convention, then, status messages and other "informational" content is output to stderr (some version of fwrite(stderr, informational_data);, and the data required for normal operations of the program are written to stdout.

Community
  • 1
  • 1
hunteke
  • 3,648
  • 1
  • 7
  • 17
  • Thanks that worked which is the main thing, but why would they write a package which outputs to `stderr` when it's not an error message? – cardamom Feb 13 '18 at 14:32
  • The syntax `cmd &> file` is a non-standards compliant bash extension. Some shells will actually follow the standard and run cmd in the background followed by a second command (a no-op) which truncates the file. Better to write `cmd > file 2>&1` – William Pursell Feb 13 '18 at 14:33
  • @WilliamPursell you are of course pedantically not wrong. Good point. – hunteke Feb 13 '18 at 14:36
  • 2
    @cardamom Some programs that expect their output to be parsed further will chose to write everything that is not part of their expected output to `stderr` even if it is not an error message. Things like reporting input parameters back. – Arne Feb 13 '18 at 14:39
  • @Arne thanks that clarifies it, the snakefood author chose to do it that way. Possibly it is also Mac versus Linux behaviour.. "some shells" – cardamom Feb 13 '18 at 14:42