-
Notifications
You must be signed in to change notification settings - Fork 481
Improve AutoHelp and AutoVersion handling #686
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
base: develop
Are you sure you want to change the base?
Improve AutoHelp and AutoVersion handling #686
Conversation
- Add option to give --help and --version the standard shortnames of -h and -V - Allow specifying --help and --version anywhere in command line - Many unit tests to verify that it all works properly
What about logging options? In our project we use |
The version option is |
@rubin55 Assuming you meant -v / --version, then the way I wrote this, it's not possible to override the shortname for the automatically-generated --help and --version options. (You could always go with AutoVersion = false and then create your own and handle it yourself, of course). I decided to do it that way because this library is designed to mimic the behavior of getopt, the standard option-parsing library on Unix. And although getopt doesn't specify what the shortname of --version should be, there's general consensus among authors of Linux-based command-line software to use -V (uppercase) as the shortname of --version. See http://www.catb.org/~esr/writings/taoup/html/ch10s05.html where there's a list of more or less standard single-character options and what they usually mean. Note how -v (lowercase) is used for --version in only a few utilities, and the page says "More usually this action is invoked by Now, having said that, there is a way that you can cause -v (lowercase) to be accepted as the shortname for --version. Just put A second reason for hardcoding the shortnames in this PR is that I wanted the settings to be booleans, not characters. If I made the settings characters then a lot of people (including myself) would be annoyed by the inconsistency of having AutoHelp be a boolean but AutoHelpShortName be a character. If it's an AutoSomething property, I thought to myself, it should just be a "turn this on and the library will do everything for me" feature, which means choosing the shortname. And so I looked up what the de facto standard is for --version, discoverd it was uppercase -V, and went with that. |
P.S. http://www.catb.org/~esr/writings/taoup/html/ch10s05.html also says of the Now, having said that, I'd like to take a poll. Please use GitHub reactions on this comment to indicate your preference:
|
I normally don't like to bump issues/PRs but seeing as it's been 2 years since the last comment I think it's worth following up on. What would it take to get this merged? Perhaps it's something simple and just requires a volunteer? |
Soo in 2024 when we expect to get this -h (or custom short name) implemented? |
Could we also address this shortcoming here: #841 |
This PR adds the ability to give --help and --version the standard shortnames of -h and -V, controlled by two ParserSettings properties. It also allows specifying --help and --version anywhere in command line rather than only at the start of the command line, as per the GNU Coding Standards for the
--help
and--version
options.This PR also includes many unit tests to verify that all the possible --help and --version scenarios work properly
This is essentially #608 rebased on top of the
develop
branch. Note that some tests rely on the new GetoptMode feature introduced in #684. I've written this PR so that it can be merged as-is, so those unit tests are commented out at the moment. But if #684 is merged first (as I would prefer) then I'll rebase this PR on top of the post-merge state ofdevelop
and uncomment those unit tests so that they will work.Fixes #600.
Fixes #596.