[stdout stream] Added an option to stream outputs

[elafarge]

• By default, dogwrap now forwards the stdout and stderr of the command
  it executes to the terminal launching dogwrap.
• This behaviour can be prevented using the --buffer_outs option
  (dogwrap then acts just as it used to do)
• I also added some comments in the code.
• Finally, I added help messages for the different possible options, as
  well as an "USAGE" description and and version number (automatically
  enabled --version option for dogwrap).

[yannmh]

Should we make it True by default ? I think we might want to use this option more often than we won't.

[elafarge]

Yeah, I was wondering as well but so far the behaviour was to have it set to false and I thought maybe some of our clients use dogwrap in some scripts of their owns. So basically I did that for "backward compatibility" but since dogwrap has been released very recently maybe we can put it to True by default. Shall I do that ?

[yannmh]

I don't think 'flushing live' versus 'once the command is completed', can introduce backward compatibility.

[yannmh]

Did you have a chance to test with Python 2.6 and Python >= 3.3 ?

[yannmh]

This fix #33
Thanks @elafarge !

cc @ddaniels888

[degemer]

Quick remark about the command line option:
-f for most Linux commands mean --force, so you might want to choose another letter (-d for --debug maybe if it's optional?) to avoid confusion.

[yannmh]

I can't think about any reason why we would rather have the output provided once the command is completed (versus 'real-time'). Should we just drop it and avoid an extra option ?
@ddaniels888 any thoughts ?

[elafarge]

Yeah, I dont see either to be honest. Maybe we can just enable it by default and add a -b option for (--buffer-outputs) so that we get rid of this letter issue at the same time !

Also maybe adding a --mute or --silent option to prevent the output from being printed may be a good idea even though it's also almost as easy to just redirect the output of dogwrap to /dev/null. What do you guys think ?

[elafarge]

I don't really see any use case for the -b option but it doesn't hurt to keep it "just in case".
But I think many users would be glad to use dogwrap in shell scripts, and therefore they would probably prefer it to be silent ?

[yannmh]

I like the idea of --silent and -b.

[yannmh]

👌

[ddaniels]

Thanks for doing this—I'm super happy to have realtime output! 👍

Generally, I'm for less flags until we see an actual use case for them.

If we can reliably provide realtime output, I don't see any reason not to. But so long as it isn't much extra code, I guess it's nice to leave the --buffer option in case someone was relying on that (for reasons I don't know).

I also don't see much case for --silent. I think just doing the standard pipe to /dev/null if you want that is easier, and requires no extra code to test/maintain.

[elafarge]

Ok Doug, I just got rid of the silent option. PR should now be ready to be merged.