Skip to content

Conversation

TheMagician23
Copy link

This PR is designed to fix #72.

The design decision I've made is to just remove the code that existed to register the -h/--help options as a "special condition", but to retain the code that automatically generates the help text from the specified options.
This allows consumers of the library to specify their own help options however they choose and have it be parsed the same as any other option.

I've written a new example file (examples/05_help.lua) to show one of the ways it can be implemented by a consumer.

Copy link
Member

@alerque alerque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't feel right. We're trying to fix the behavior to be in line with standard POSIX and general *nix ecosystem expectations. Special handling for --help and --version that short-circuit the rest of option processing is quite normal, the only issue is that those conditions are not considered failures they are success states because they are expected based on user input.

We can of course optionally provide a way for users to retrieve the help text and handle it themselves (which would imply a way to disable the automatic handling), but I think we should maintain compatibility with the current interface so that the exit code fix can be released in a mere patch version that isn't a breaking change for everybody. If we also include a new feature that would imply a minor release bump, but still not breaking so no not a breaking v4 release that requires all downstream projects to adapt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Parsing --help needs to return something other than an error

2 participants