undefined

points

[-]

> 3. Generally, you can always tell if something is going wrong by grepping for errors or warnings a single stream (stderr), or by looking for a nonzero exit code.

I'll use ffmpeg as an example of being an edge case. It's hard to get ffmpeg to give a nonzero exit code. What might be a problem for the user wasn't necessarily a problem for the app, so the app thinks it is completed and does its thing exiting with zero. For example, if a file is being read as input that is corrupted causing ffmpeg to no longer be able to read from the source, it will happily close your file cleanly so it is usable (just shorter than expected) and report it completed successfully. If all you do is check the exit code, you'll think your file is completed. Much more due diligence is necessary to be sure.

by IsTom4 hours ago|

parent|

[-]

Last time I had that problem -xerror helped.

by anyfoo13 hours ago|

prev|

[-]

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

by archargelod1 hours ago|

parent|

[-]

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

by ryandrake13 hours ago|

parent|

prev|

[-]

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

by anyfoo12 hours ago|

parent|

[-]

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

by dylan60411 hours ago|

parent|

[-]

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

by ryandrake12 hours ago|

parent|

prev|

[-]

Out of the problems we all agonize over, this is probably a 1 out of 10!

by ramses010 hours ago|

parent|

prev|

[-]

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.