Closed vbauerster closed 6 years ago
Printing help to stderr is standard practice. Try httpstat --help 2>&1 | grep <pattern>
.
@moorereason Absolutely valid, but more and more tools are moving to using stdout because of the poor UX of printing to stderr
.
I think this is valid. It shits me that I have to pipe the output of most of the things the go tools does through 2>&1
I haven't reviewed the patch yet and probably won't have time to before I leave for Japan. It did seem more involved than appeared necessary to me, shouldn't the usage function just print to stdout?
On Sun, 27 Nov 2016, 09:25 Tim Heckman notifications@github.com wrote:
@moorereason https://github.com/moorereason Absolutely valid, but more and more tools are moving to using stdout because of the poor UX of printing to stderr.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/pull/116#issuecomment-263089597, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcAxRZzPokljKxPu12RZ2QDTgwxDHCks5rCLHUgaJpZM4K85A2 .
@moorereason Could you please be so kind and name a tool which prints to stderr with --help flag?
The general workflow (try curl
or ffmpeg
for example):
$ curl | grep <pattern>
curl: try 'curl --help' or 'curl --manual' for more information
# exit status > 0
$ curl --help | grep <pattern>
# output of grep
# exit status = 0
Also go-flags
package, which is alternative to the standard flags package, follows this convention.
This is not to say, that the standard flags package is wrong, but its default behaviour to print to stderr with --help flag.
@vbauerster,
It looks like most tools print --help
to stdout these days (sed
is one that doesn't), but when an invalid option is given, many print usage to stderr (see sed
, tr
, wc
)...although, many don't(?!). I prefer to have errors on stderr, and your PR handles that the way I would expect. I missed that while looking at your patch earlier, so I removed my thumbs-down on your initial comment. Ready, Fire, Aim! My fault.
@moorereason Thank you for your valuable reply!
I think httpstat --help
should return with exit status = 0 (like curl does), which my PR is not handling at the moment. Let me revise it.
Well I've tried not to be a frog in a well, but couldn't avoid this line.
But that actually makes httpstat --help
exit with status code 0.
@davecheney
shouldn't the usage function just print to stdout?
If you agree that this case, can print to stdout instead of stderr, I just vote for this.
httpstat --help
writes to stderr, which makes output not greppable.For example following will fail:
httpstat --help | grep <pattern>
From user perspective
cmd --help
, which outputs to stderr is also confusing, as there is no any indication of error.This PR fixes this confusion.