stdout Is Not for Messages

> And I'm also talking to you, "12-factor app". Shame on you. You could be so great. This single thing makes you incompatible with the entire Unix philosophy.

Because it's not a Unix CLI tool... And obviously cluttering stderr with informational messages has downsides too. "stdout for info, stderr for error" works pretty well for servers (what else are you supposed to use stdout for?)

It never actually says why this is supposedly bad. This is just repetition of a slogan with zero actual content. I have yet to encounter a "rule" that shouldn't be broken at least on occasion, and without the reasoning you don't know when you're supposed to break it.

What about the psychos that print help messages to stderr so you get nothing from grep and have to run the command again piping stdout to stderr?

That ship has sailed. Choices are stdout or stderr. Given those names, I'll of course send errors to stderr, leaving me with stdout for messages/infos/logs.

Most applications nowadays use stdout for exactly what the name implies - any form of output. Complaining about that is yelling at the clouds.

STDOUT is for data, STDERR is for commentary. If your program is a server, then its logs are data, not commentary. I’d have them on STDOUT so I can `myServer | grep myBug`.

If your program is a data processing tool, then you should avoid printing any logs ideally, and those go to STDERR. A misplaced log on STDOUT will break readers who expect you to be writing JSON or another well specified format on STDOUT.

Agreed. Unless the messages are the main output users would pipe I guess.

I'd add to this, write tools that support proper piping in general. It's tempting to just get users to pass input file and then spew messages while processing. Instead why not allow piping in the contents. So many more uses are possible now.

I never really even entertained the idea of agreeing with this until just this week actually, when I was putting log statements into bash functions that were supposed to return strings -- and failed for reasons I could not understand. Six full hours of debugging later, I realized that the logs were writing to stdout, and thus were cluttering the expected return values.

I'm still not fully sold on the idea, but I now have at least one tangible example of when you would want to keep stdout clear of commentary.

To add insult to injury in java 8 you can't output gc log info anywhere else than to stdout...