Skip to content
This repository has been archived by the owner on Oct 28, 2021. It is now read-only.

Provide a built-in way of dealing with --help option #8

Closed
vadz opened this issue Mar 4, 2016 · 2 comments
Closed

Provide a built-in way of dealing with --help option #8

vadz opened this issue Mar 4, 2016 · 2 comments

Comments

@vadz
Copy link
Contributor

vadz commented Mar 4, 2016

Almost(?) all command line programs will have the --help option so IMO it would make sense to either support it out of the box or at least make it simpler to implement it than currently as it involves many steps:

  1. Call bindProcessName() (it's not going to be used for anything else than the usage message).
  2. Add bool help to the options struct.
  3. Bind -h and --help to it.
  4. Call usage() if help is true.

I'd rather have a way to tell parse() to do all of this automatically, but this would require changing its return type, as we need to know whether help was requested or not, so maybe a better idea would be to add another method, e.g. parse_or_give_help() returning bool.

OTOH I think it's quite wrong for parse() to throw on command line syntax errors, this is not something exceptional and can (and does) happen all the time. So personally I'd rather change parse() to return an enum indicating whether the command line was successfully parsed, an error occurred or help was requested.

@philsquared
Copy link
Collaborator

Yeah, I've had all the same thoughts - and a few ideas about how to address them - but not been entirely satisfied with any of them yet.
Still thinking...

@philsquared
Copy link
Collaborator

The new version of Clara, which has been completely rewritten (warning: very breaking changes), now has a dedicated Help() parser which, I believe, does what you want.
Also the new Clara uses a Result type for error propagation, rather than exceptions. Hopefully this is much closer to what you wanted (if you're still interested - obviously your original issue was raised a while ago)

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

No branches or pull requests

2 participants