1

I have seen stdout and stderr used in a variety of different ways - as far as I understand, it is common to use stdout for general information and stderr for errors and the like. However, I have also seen stderr used to output information messages related to the program itself (but not related to errors, warnings, debugging etc) and for debugging purposes (I assume the latter uses the error stream so that it can be filtered out to aid debugging), and stdout for the more serious warnings which I would have thought would have belonged in stderr.

So, I was wondering - when is it seen as ideal to use stdout or stderr in relation to what the program is outputting, aside from general output and errors? Is it more program-dependent, or more generic than that?

Joe
  • 1,404
  • 1
  • 12
  • 18

3 Answers3

2

The reason for having separated stdout and stderr in the first place is to distinguish between program data output (which might be stored in a file, fed to a pipeline, &c.) and diagnostics and fluff (which are only really of interest to a human operator looking at the terminal). (There's no automatic way of doing the same for input, but you can do it with a bit more trouble by opening and reading the controlling terminal device rather than stdin.) Thus, if you have the choice between writing something on stdout or stderr, the best heuristic is probably "Will this data be of interest to another program using my output?" However, this can be program- and application-dependent, and so there isn't a single overriding rule. (This is why there are override options, such as 2>&1 and so forth in bash.)

Tom Hunt
  • 10,056
  • So stderr is more for program-to-program or some other kind of not-really-for-the-user type of output, and stdout is for general output to the user? – Joe Dec 03 '15 at 21:19
  • 1
    Other way around. And it isn't that stdout isn't for the user, though it may not be, but that it's the main expected result of the program (possibly as a transformation of the input), while stderr is for exceptional conditions. – Tom Hunt Dec 03 '15 at 21:30
  • Ah, OK, that clears things up for me. So stderr shouldn't be used for errors or logging really, but it is used for that? – Joe Dec 03 '15 at 22:44
  • It could be used for errors or logging if you wanted. It's just a second output stream that can easily be separated from stdout if you want. – Tom Hunt Dec 03 '15 at 23:03
2

It depends! One relevant factor is that stderr is unbuffered by default, as one would not like to loose an error message to buffering when something fails, while stdout is line (terminal) or block (otherwise) buffered by default. This is more efficient, though failures may cause the loss of a line or blocks worth of data. Another is what the program outputs; if something is emitting a particular format, say, CSV, or JSON, mixing error messages into that could corrupt it (or require encoding in the particular format and then what happens if there's an error encoding it in that format abort! abort! abort!), while in other cases (an interactive menu type system?) mixing error messages with other output may not matter as much.

thrig
  • 34,938
  • Out of interest, are you saying that the encoding of stdout and stderr could be different? Wouldn't the terminal sort out encoding, or is there the chance of different encodings between streams? – Joe Dec 03 '15 at 22:42
  • @Joe "encoding" here would be CSV or XML or JSON, not character encoding, though poor programming could easily mix different types of encoding over the same stream (e.g. I've seen Windows applications that switch mid TCP stream from UTF-8 to UTF-16LE). – thrig Dec 03 '15 at 23:28
  • ah OK, so the two streams allow you to filter them out? – Joe Dec 04 '15 at 08:31
2

Always think that someone will put your program in a pipeline at some point:

$ inputProducer | yourProgram | outputConsumer

When considering whether to direct something to stderr or stdout, what matters is whether that something is relevant to (a generic) outputConsumer or whether it would only make its life harder.

  • Relevant: stdout
  • Irrelevant: stderr

( Beware that lots of error reporting goes to stdout instead of stderr because people forget to redirect it to stderr, even though that would have been the better choice. )

Petr Skocik
  • 28,816
  • 1
    Very true. It's annoying when a program doesn't use the correct streams (but then there's no real "definition" as such to use). – Joe Dec 15 '15 at 16:24