3 ms·

It's POSIX convention to write to stderr for anything that's not strict program output. I have seen 2>&1 far too often in scripts. I don't worry about it and ha

It's POSIX convention to write to stderr for anything that's not strict program output. I have seen 2>&1 far too often in scripts. I don't worry about it and happily write error messages to stderr whenever my scripts exit without a 0 status code.

ryandrake 5mo ago
Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script or pipe, and get a bunch of usage output in stdout, a downstream consumer of that stdout might think its legit program output and try to parse it. 2. If your user actually calls the program with -h or --help, they might want to |less through it to read it on a small terminal screen. Output that to stdout. 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. But your general principle applies: Output expected by the user -> stdout. Diagnostic output or output incidental to the program's operation or errors -> stderr. 1: https://pubs.opengroup.org/onlinepubs/9799919799/functions/stdin.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/s...
- anyfoo 5mo 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`.
  - ryandrake 5mo 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.html https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....
    - anyfoo 5mo 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...
      - ryandrake 5mo ago
        Out of the problems we all agonize over, this is probably a 1 out of 10!
      - dylan604 5mo 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
  - tardedmeme 5mo ago
    I see you've never tried to run command --help | less
    - anyfoo 5mo ago
      I just said that I always do `command --help 2>&1 | less`?
      - tardedmeme 5mo ago
        Pretty annoying. Wouldn't it be good if command --help would just display the help?
    - king_geedorah 5mo ago
      Honestly if your help output requires the use of a pager or a text search utility to be useful I question why you didn’t just write a man page in the first place.
  - ramses0 5mo 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.
  - archargelod 5mo 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!
- dylan604 5mo ago
  > 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.
  - IsTom 5mo ago
    Last time I had that problem -xerror helped.
deleted 5mo ago
[deleted]

ryandrake 5mo ago

Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script or pipe, and get a bunch of usage output in stdout, a downstream consumer of that stdout might think its legit program output and try to parse it. 2. If your user actually calls the program with -h or --help, they might want to |less through it to read it on a small terminal screen. Output that to stdout. 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. But your general principle applies: Output expected by the user -> stdout. Diagnostic output or output incidental to the program's operation or errors -> stderr. 1: https://pubs.opengroup.org/onlinepubs/9799919799/functions/stdin.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/s...

anyfoo 5mo 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`.
- ryandrake 5mo 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.html https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....
  - anyfoo 5mo 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...
    - ryandrake 5mo ago
      Out of the problems we all agonize over, this is probably a 1 out of 10!
    - dylan604 5mo 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
- tardedmeme 5mo ago
  I see you've never tried to run command --help | less
  - anyfoo 5mo ago
    I just said that I always do `command --help 2>&1 | less`?
    - tardedmeme 5mo ago
      Pretty annoying. Wouldn't it be good if command --help would just display the help?
  - king_geedorah 5mo ago
    Honestly if your help output requires the use of a pager or a text search utility to be useful I question why you didn’t just write a man page in the first place.
- ramses0 5mo 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.
- archargelod 5mo 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!
dylan604 5mo ago
> 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.
- IsTom 5mo ago
  Last time I had that problem -xerror helped.

deleted 5mo ago

[deleted]