-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asking for help with '-h' is not an error #45
Comments
Thank you, @ernstki! You make an excellent point here, and one that I hadn't really considered like this before. But you're absolutely right, and I would love to change the behavior to what you're suggesting here. |
For a long time, I didn't even understand why sometimes Does it bother you to change this behavior in a I have a few other PRs here that I've come back to wrap up, but I'm happy to do the twenty minutes of search-and-replace work necessary to make this change across the entire toolbelt. |
Yeah, this will be much better behavior for beginners.
Not at all! I don't really consider this a program change, but like a (minor) update to the help text itself.
Thank you, that will be very much appreciated! 🙏 |
Vincent, might I convince you that it's not an error to ask for help?
What I mean by that is that
-h
output should go to standard out (so it can piped straight into another tool such asgrep
orless
without weird redirections) and thatgit toolbelt-utility -h
should return zero exit status, rather than non-zero.Probably none of the git-toolbelt utilities fall into this category, but one thing I find personally frustrating is when a program's
--help
is pages long, and yetcommand --help | less
doesn't work (because the output goes to stderr). Now, I know that|& less
or2>&1 | less
will work, but does everyone?If the user supplies an invalid argument (or no arguments), then yes,
usage >&2; exit 2;;
is warranted. No disagreement there.I will of course defer to your own philosophical leanings here, and especially if you're of the SemVer persuasion, since this would warrant a 2.0 release, as it breaks the existing git-toolbelt API, as it were, albeit in a benign way.
The text was updated successfully, but these errors were encountered: