Parser config option to allow user control of -h
#282
Conversation
Because I'm often wanting to use `-h` for "hostname", etc., the claiming of it by `go-arg` is annoying. This PR adds a config option named `IgnoreShortHelp` which prevents `go-arg` from claiming `-h`. `--help` is still left for `go-arg` to handle.
|
Thanks for this @rjp. Would you be open to changing this so that the config option is where each element of the slice is expected to be a string like "--help", "-h", etc? If config.Help is nil then it should default to In your case you would set it to |
|
Yeah, good idea, I'll get on that later |
Instead of `IgnoreShortHelp`, there's now `Help` which is a slice of
strings that will be treated as help options. If the slice is `nil`,
it'll default to `[]string{"-h", "--help"}` to emulate the existing
behaviour. Otherwise only options in the slice will activate "help".
parse.go
Outdated
| @@ -519,11 +518,12 @@ func cmdFromStruct(name string, dest path, t reflect.Type, envPrefix string) (*c | |||
| func (p *Parser) Parse(args []string) error { | |||
| err := p.process(args) | |||
| if err != nil { | |||
| if errors.Is(err, ErrHelp) { | |||
There was a problem hiding this comment.
Unless I'm mistaken, this won't do what the loop below previously did. The issue is that if you have, say, a program with a single flag:
var args struct {
S string
}And the user writes on the command line
./program --s --helpThen the program will now complain with something like "--s requires a value". But in this case we really want to print help output, not the error about --s.
I don't think the errors.Is check here will change that because the library will just bail when it encounters the first error (correct me if you already tested this and I'm remembering wrong).
There was a problem hiding this comment.
I seem to have tested everything but that. You're right, it doesn't trigger the help. I'll have a think.
There was a problem hiding this comment.
Thanks for putting this together @rjp. I'm afraid there is a bit more work to do because the help and usage information should reflect the help options configured in this way. Not sure if you have time/inclination to look at that - no problem if not, I should be able to look into it in the next few days.
Also for reason this PR is showing a diff versus the previous version of this feature. Any idea what's up with that? Again, no problem if you don't have time, I can pull the branch over and work on it at my end if needed.
Correctly handles the `--s --help` test (should display help, not complain about a missing argument for `--s`.)
+ Test that one long and one short option in `config.Help` works fine. + More will confuse things.
Latest push addresses this but will only work properly for one short and one long option in |
Because I'm often wanting to use
-hfor "hostname", etc., the claiming of it bygo-argis annoying. This PR adds a config option namedIgnoreShortHelpwhich preventsgo-argfrom claiming-h.--helpis still left forgo-argto handle.