3 ms·
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 gettin
by 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 agoYour reply doesn't take into account the second paragraph of my comment.
- deleted 3y ago[deleted]
- xigoi 3y agoWhen 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.