views:

180

answers:

3

I'm making a script that handles a predefined set of data, outputting to a file. I want to pop up a warning when one datum (which is always "Regular" in every set that I've had access to) is different stating that this value is unhandled (since I don't know how it affects the data). Should I output this warning to stderr or stdout?

+7  A: 

If I saved the output of this script (i.e. stdout only) so that I could process it later, would that warning interfere with how the output is parsed? Moreover, if output is piped to another process, the warning should show up on the terminal, so the user sees it immediately.

For those reasons, in general, you output warnings to stderr.

Mark Rushakoff
+1  A: 

The real question is: if someone were to redirect the output of your script to a file, would you want the warning placed in the file, or directed to the user?

If you're expecting the user to take some action as a result of the warning, it should go to STDERR. If some downstream script is likely to be tripped up by the warning, it should go to STDERR.

Martin
So it should go to stderr regardless? Or did you intend one of the two references to STDERR to be STDOUT?
Jonathan Leffler
I meant STDERR on both. They are two cases where you pretty much have to send it to stderr. The only time I can think of wanting it to go to stdout is if the script's output is for human consumption (maybe you're going to email the output to someone to have a look over it), and you might want the warnings to follow the output without having to remember to redirect stderr.
Martin
+2  A: 

The warning should go to stderr.

In addition to the points presented by others (causing parsing errors for downstream processes and hiding the error from the user at the console), there is an issue of flexibility.

If the user does not want the warning from stderr to go to a downstream process that is parsing stdout, they don't have to do anything special.

your_script | downstream_process

If the user wants the warning from stderr to go to a downstream process that will parse stdout and stderr, the user can use 2>&1 to redirect stderr into stdout.

your_script 2>&1 | downstream_process

If you output both warnings and any normal data to stdout, the user has no good way of separating the warnings from the data without parsing everything. So sending the warnings to stderr gives your script more flexibility as well.

Michael Berg

related questions