4 ms·

I disagree. stderr is a misnomer, in modern usage it has effectively become stdlog/stdinfo. The only thing that should go to stdout is the result of the program

I disagree. stderr is a misnomer, in modern usage it has effectively become stdlog/stdinfo. The only thing that should go to stdout is the result of the program. For example, many programs will print usage/help when used incorrectly. Imagine you upgrade the "read_reactor" tool, and your usage in your "control_reactor" becomes invalid - suddenly you're piping help message data to the control rods. By sending it to stderr instead, no bogus data would be piped and, as a bonus, you would see the help message after invoking your script because (as you have experienced) stderr is not piped by default. If you want to send it to less: read_reactor -h 2>&1 | less

oasisbob 3y ago
> Imagine you upgrade the "read_reactor" tool, and your usage in your "control_reactor" becomes invalid As others have noted, that's an error which shouldn't go to stdout. But help text is not an error. It's arguably the expected and primay output of the help function.
School-Cotton 3y ago
When passing dash dash help, the help is the output of the program, so it should go to stdout. When help is printed because the invocation was invalid, it should go to stderr. This is what most programs do, btw.
recursive 3y ago
Modern usage is a misnomer. When invoked with --help, help is the result of the program.
- benatkin 3y ago
  I disagree, the program's purpose isn't to show the help. Asking directly for help is one of the things in the path to getting desired output, along with getting an error. If you're following such and such standards that says it should go to stdout, it should go to stdout though. I don't take that as a given. I agree with this remaining open after all of these years: https://github.com/commandlineparser/commandline/issues/399 https://github.com/commandlineparser/commandline/issues/399 OP should add 2>&1 before the pipe or replace the pipe with |& (bash) or &| (fish)
  - dredmorbius 3y ago
    <https://news.ycombinator.com/item?id=37683629 https://news.ycombinator.com/item?id=37683629> <https://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....> Contradicts your argument.
    - benatkin 3y ago
      Your reply doesn't take into account the second paragraph of my comment.
  - deleted 3y ago
    [deleted]
  - xigoi 3y ago
    When invoked with --help, the program's purpose is to show the help.
  - sph 3y ago
    > If you're following such and such standards that says it should go to stdout, it should go to stdout though. I don't take that as a given. This is being pedantic. If 99% of programs operate a certain way (GNU coreutils or their BSD equivalent), while not dogma, it becomes convention. You need a good reason to break convention than whatever rationalisation you seem to have against it. The comment in the linked github issue does not present any advantage to using stderr (lack of buffering, really?) yet they completely ignore convention. Quit being fancy, be a good GNU/BSD citizen.
- ImaCake 3y ago
  Bingo. The arguments for making unix harder than it has to be by sending help to stderr when the user has asked for it is the kind of stuff that gives linux it’s bad reputation.
  - School-Cotton 3y ago
    AFAIK all standard tools on typical Linux distributions send help to stdout when it’s been asked for, and to stderr when it’s a response to a malformed command. Third parties can make their software do whatever they want, but that’s hardly “Linux”’s fault.
deleted 3y ago
[deleted]
pmarreck 3y ago
... Is there a concept of a STDLOG or a STDINFO ? (STDDEBUG etc.) These sound useful, in any event. I'd also like to be able to pipe both STDOUT and STDERR to the next in a sequence of pipes, but eh
- zamalek 3y ago
  You could use &3 etc, but that's non-standard. 2>&1 does pipe both into stdout, you would have to do 1>/dev/null 2>&1 to get stderr only going to stdout.
- seniorsassycat 3y ago
  |& pipes both
  - follower 3y ago
    Yes! And |& is so much easier to remember than 2>&1 or is it 1&>2?! I'm sure there's some obscure reason why |& isn't the one people suggest first but when I learned about it recently it was hugely useful. (And if I haven't learned the correct ordering for the > variant by now I think it's fair to assume I was never going to do so...)
    - fragmede 3y ago
      It didn't exist until "recently", but my mnemonic for 2>&1 is two goes to one, but not just one, but to the same place as one, so you have to dereference it with an ampersand.
      - follower 3y ago
        Thanks for sharing, now I think I can't remember either approach. :D But I'm glad the mnemonic works for you. :)
    - hn92726819 3y ago
      > I'm sure there's some obscure reason |& isn't POSIX. As for the redirection order, if you haven't learned it yet, learn now! These numbers arent magic. 0 is stdin, 1 is stdout, and 2 is stderr. These are the free file descriptors you get on Unix and on Windows. Stdout (1) from previous process goes to stdin (0) in the next process in a pipeline. So, if you want less to see the previous processe's stdout (1) and stderr (2), you just need to tell shell "send stderr to wherever stdout is going right now". That's exaxtly what 2>&1 means. A fun caveat about this syntax is the difference between these two: ls >/dev/null 2>&1 ls 2>&1 >/dev/null The first one tells stderr to go to dev null ("where stdout is going right now"), and the second one sends stderr to the next process and stdout to dev null

oasisbob 3y ago

> Imagine you upgrade the "read_reactor" tool, and your usage in your "control_reactor" becomes invalid As others have noted, that's an error which shouldn't go to stdout. But help text is not an error. It's arguably the expected and primay output of the help function.

School-Cotton 3y ago

When passing dash dash help, the help is the output of the program, so it should go to stdout. When help is printed because the invocation was invalid, it should go to stderr. This is what most programs do, btw.

recursive 3y ago

Modern usage is a misnomer. When invoked with --help, help is the result of the program.

benatkin 3y ago
I disagree, the program's purpose isn't to show the help. Asking directly for help is one of the things in the path to getting desired output, along with getting an error. If you're following such and such standards that says it should go to stdout, it should go to stdout though. I don't take that as a given. I agree with this remaining open after all of these years: https://github.com/commandlineparser/commandline/issues/399 https://github.com/commandlineparser/commandline/issues/399 OP should add 2>&1 before the pipe or replace the pipe with |& (bash) or &| (fish)
- dredmorbius 3y ago
  <https://news.ycombinator.com/item?id=37683629 https://news.ycombinator.com/item?id=37683629> <https://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....> Contradicts your argument.
  - benatkin 3y ago
    Your reply doesn't take into account the second paragraph of my comment.
- deleted 3y ago
  [deleted]
- xigoi 3y ago
  When invoked with --help, the program's purpose is to show the help.
- sph 3y ago
  > If you're following such and such standards that says it should go to stdout, it should go to stdout though. I don't take that as a given. This is being pedantic. If 99% of programs operate a certain way (GNU coreutils or their BSD equivalent), while not dogma, it becomes convention. You need a good reason to break convention than whatever rationalisation you seem to have against it. The comment in the linked github issue does not present any advantage to using stderr (lack of buffering, really?) yet they completely ignore convention. Quit being fancy, be a good GNU/BSD citizen.
ImaCake 3y ago
Bingo. The arguments for making unix harder than it has to be by sending help to stderr when the user has asked for it is the kind of stuff that gives linux it’s bad reputation.
- School-Cotton 3y ago
  AFAIK all standard tools on typical Linux distributions send help to stdout when it’s been asked for, and to stderr when it’s a response to a malformed command. Third parties can make their software do whatever they want, but that’s hardly “Linux”’s fault.

deleted 3y ago

[deleted]

pmarreck 3y ago

... Is there a concept of a STDLOG or a STDINFO ? (STDDEBUG etc.) These sound useful, in any event. I'd also like to be able to pipe both STDOUT and STDERR to the next in a sequence of pipes, but eh

zamalek 3y ago
You could use &3 etc, but that's non-standard. 2>&1 does pipe both into stdout, you would have to do 1>/dev/null 2>&1 to get stderr only going to stdout.
seniorsassycat 3y ago
|& pipes both
- follower 3y ago
  Yes! And |& is so much easier to remember than 2>&1 or is it 1&>2?! I'm sure there's some obscure reason why |& isn't the one people suggest first but when I learned about it recently it was hugely useful. (And if I haven't learned the correct ordering for the > variant by now I think it's fair to assume I was never going to do so...)
  - fragmede 3y ago
    It didn't exist until "recently", but my mnemonic for 2>&1 is two goes to one, but not just one, but to the same place as one, so you have to dereference it with an ampersand.
    - follower 3y ago
      Thanks for sharing, now I think I can't remember either approach. :D But I'm glad the mnemonic works for you. :)
  - hn92726819 3y ago
    > I'm sure there's some obscure reason |& isn't POSIX. As for the redirection order, if you haven't learned it yet, learn now! These numbers arent magic. 0 is stdin, 1 is stdout, and 2 is stderr. These are the free file descriptors you get on Unix and on Windows. Stdout (1) from previous process goes to stdin (0) in the next process in a pipeline. So, if you want less to see the previous processe's stdout (1) and stderr (2), you just need to tell shell "send stderr to wherever stdout is going right now". That's exaxtly what 2>&1 means. A fun caveat about this syntax is the difference between these two: ls >/dev/null 2>&1 ls 2>&1 >/dev/null The first one tells stderr to go to dev null ("where stdout is going right now"), and the second one sends stderr to the next process and stdout to dev null