← Back to context

Comment by anyfoo

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

8 comments

anyfoo

Reply
ryandrake  12 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  12 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  10 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  9 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.