3 ms·

stdout Is Not for Messages

18 points by alexzeitler 3y ago

throwaway290 3y ago
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.
- aeonik 3y ago
  Do you have a guide that you can share that talks about strategies on how to do this? Best practices, common pit falls, etc...
  - throwaway290 3y ago
    I don't but articles about this topic are posted on HN sometimes
bogantech 3y ago
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?
- invalidator 3y ago
  In my opinion, if you asked for --help, the help IS the program's output, and should go to STDOUT. Unsolicited help messages for incorrect command lines ought to go to STDERR. It's especially frustrating for programs which only write to files or something, and never produce output on STDOUT.
  - l0b0 3y ago
    --help is special, but there's also programs which don't distinguish between that and a syntax error. --help should go to stdout, --no-such-flag should go to stderr, even if they are identical messages.
arp242 3y ago
> 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.
mschuetz 3y ago
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.
jitl 3y ago
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.
ryapric 3y ago
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.
awelxtr 3y ago
To add insult to injury in java 8 you can't output gc log info anywhere else than to stdout...

18 points by alexzeitler 3y ago

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.

aeonik 3y ago
Do you have a guide that you can share that talks about strategies on how to do this? Best practices, common pit falls, etc...
- throwaway290 3y ago
  I don't but articles about this topic are posted on HN sometimes

bogantech 3y ago

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?

invalidator 3y ago
In my opinion, if you asked for --help, the help IS the program's output, and should go to STDOUT. Unsolicited help messages for incorrect command lines ought to go to STDERR. It's especially frustrating for programs which only write to files or something, and never produce output on STDOUT.
- l0b0 3y ago
  --help is special, but there's also programs which don't distinguish between that and a syntax error. --help should go to stdout, --no-such-flag should go to stderr, even if they are identical messages.

arp242 3y ago

> 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.

mschuetz 3y ago

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.

jitl 3y ago

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.

ryapric 3y ago

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.

awelxtr 3y ago

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