Skip to content
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

Improve AutoHelp and AutoVersion handling #686

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

rmunn
Copy link
Contributor

@rmunn rmunn commented Aug 19, 2020

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 of develop and uncomment those unit tests so that they will work.

Fixes #600.
Fixes #596.

- 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
@Olympic1
Copy link

What about logging options? In our project we use -v to enable verbose logging, will this conflict with the version option?

@rmunn
Copy link
Contributor Author

rmunn commented Aug 19, 2020

The version option is -V (uppercase), precisely because lowercase -v is so often used for --verbose. That's a de facto standard in all the Linux software I've seen, so that's what I set it to.

@rubin55
Copy link

rubin55 commented Aug 19, 2020

@rmunn Is it possible to override? So if I want to use -v / --verbose + -h / --help I could? (that was the request in #585 at least).

@rmunn
Copy link
Contributor Author

rmunn commented Aug 19, 2020

@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 -V." (Uppercase). So I decided to try to guide people towards following the standard rather than using non-standard shortnames for --version.

Now, having said that, there is a way that you can cause -v (lowercase) to be accepted as the shortname for --version. Just put CaseSensitive = false in your parser settings. Then both -H and -h will be accepted for --help (and --HELP and --Help and --hElP will also be accepted), and both -V and -v will be accepted for --version, and so on.

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.

@rmunn
Copy link
Contributor Author

rmunn commented Aug 19, 2020

P.S. http://www.catb.org/~esr/writings/taoup/html/ch10s05.html also says of the -V (uppercase) switch that "It would be quite surprising for this switch to be used in any other way." Now, he meant that it would be quite surprising if -V (uppercase) were to mean something other than --version, which is not quite the same thing as saying that it would be surprising if --version's abbreviation were not -V (uppercase). But that does go to illustrate the point that there's a de facto standard in Unix (and now Linux) utilities, and it's the uppercase -V.

Now, having said that, I'd like to take a poll. Please use GitHub reactions on this comment to indicate your preference:

  • If you want -V and -h hardcoded as the shortnames for --version and --help respectively, please give this comment a 👍
  • If you want to be able to choose the shortnames for --version and --help (by having char, rather than bool, values for those parser settings), please give this comment a 👎
  • If you want something else (the "other" choice without which no poll is complete), please give this comment a 👀 and leave a comment explaining what you wanted that wasn't one of these two choices.

@rcdailey
Copy link

rcdailey commented Nov 9, 2022

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?

@psulek
Copy link

psulek commented May 24, 2024

Soo in 2024 when we expect to get this -h (or custom short name) implemented?

@marcopelegrini
Copy link

Could we also address this shortcoming here: #841

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants