commandline icon indicating copy to clipboard operation
commandline copied to clipboard

Improve AutoHelp and AutoVersion handling

Open rmunn opened this issue 5 years ago • 8 comments

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.

rmunn avatar Aug 19 '20 08:08 rmunn

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

Olympic1 avatar Aug 19 '20 12:08 Olympic1

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.

rmunn avatar Aug 19 '20 14:08 rmunn

@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).

rubin55 avatar Aug 19 '20 17:08 rubin55

@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 avatar Aug 19 '20 23:08 rmunn

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 :+1:
  • 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 :-1:
  • If you want something else (the "other" choice without which no poll is complete), please give this comment a :eyes: and leave a comment explaining what you wanted that wasn't one of these two choices.

rmunn avatar Aug 19 '20 23:08 rmunn

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?

rcdailey avatar Nov 09 '22 13:11 rcdailey

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

psulek avatar May 24 '24 11:05 psulek