← Back to context

Comment by anyfoo

16 hours ago

Disagree. stdout is only reserved for actual processed command output. It may be empty, it may be invalid because the input was invalid (shit in, shit out), but it may never be things intended for a human to read.

If one wants to use a pager (like I sometimes do, though most of the time I just scroll up), they'll just use `foo 2>&1 | less`.

9 comments

anyfoo

Reply
archargelod  3 hours ago

> stdout is only reserved for actual processed command output

If user asks a program to print help message, the help text is the processed command output!

ryandrake  15 hours ago

GNU offers guidance[1] to output --help to stdout, but it's not against the law to do it your way.

1: https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....

  • anyfoo  15 hours ago

    I guess this is a point where I disagree with GNU. Then again, the reasons why I disagree are subtle enough that I don't care too much... I think this particular thing doesn't matter very much in practice, so go do your thing GNU...

    • dylan604  14 hours ago

      I can see both sides. As someone automating, I could see getting the malformed command -h result to stderr. I can also see that sending -h to stdout would be expected as that is the legit out as requested by the user. At the least, if -h is sent to stdout for a malformed command then by gawd it better be a nonzero exit. With that, I think (and boy did it hurt) that it's an okay rule to break

ramses0  13 hours ago

In the case of `git log -100 | grep FOO`, the log output should go to stdout.

In the case of `git diff | grep FOO`, the diff output should go to stdout.

In the case of `git --help | grep FOO` the help output should go to stdout.

In the case of `git --omg-wtf | grep FOO`, it's fine if there is only output on stderr.