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

Custom exit code #3426

Closed
2 tasks done
tertsdiepraam opened this issue Feb 9, 2022 · 3 comments
Closed
2 tasks done

Custom exit code #3426

tertsdiepraam opened this issue Feb 9, 2022 · 3 comments
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this

Comments

@tertsdiepraam
Copy link
Contributor

tertsdiepraam commented Feb 9, 2022

Please complete the following tasks

Clap Version

3.0.10

Describe your use case

At the uutils project, we need to match the exit code of the original GNU utilities. GNU often (but not always) uses 1 as an exit code when the arguments are wrong, so we regressed when moving to clap 3 due to #1327 and #1653.

The relevant issue on our repository is uutils/coreutils#3102.

Describe the solution you'd like

I don't think there is a one size fits all solution for exit codes. Therefore, I'd like App to have some method that specifies the exit code in case of a usage error. The default would continue to be 2. It could look something like this:

App::new("test")
    .fail_exit_code(1);

I'm not sure what the best name would be. It could also be exit_code, usage_error_code or error_code.

Alternatives, if applicable

We also have our own error type with exit code information, which we could convert a clap error into. In this case we would implement conversion to our own error type and then use try_get_matches to get the error. However, this would require quite a bit of code for the conversion.

A third possible solution would be to provide a method on Error to modify the exit code before calling Error::exit(), which could be used like this:

App::new("test")
    .try_get_matches()
    .map_err(|e| e.exit_code(1).exit())

However, this solution is unintuitive for DisplayHelp and DisplayVersion, which should probably ignore this method.

Additional Context

I would be happy to try to implement this if this is indeed something you'd like to include. We're still very happy with clap! Thank you for this amazing crate!

@tertsdiepraam tertsdiepraam added the C-enhancement Category: Raise on the bar on expectations label Feb 9, 2022
@epage epage added A-parsing Area: Parser's logic and needs it changed somehow. S-wont-fix Status: Closed as there is no plan to fix this labels Feb 9, 2022
@epage
Copy link
Member

epage commented Feb 9, 2022

As part of our effort to trim down clap, we're focusing on the built-in / easy path being for the majority case while offering building blocks for the exceptions. I think exit codes fall in that boat. Here is an example of a program that provides custom exit codes: https://github.com/crate-ci/typos/blob/master/src/bin/typos-cli/main.rs#L17

I'd recommend using a testing tool like trycmd which will help in testing exit codes.

@epage epage closed this as completed Feb 9, 2022
@tertsdiepraam
Copy link
Contributor Author

I completely understand. Thank you for your time!

vincentdephily added a commit to vincentdephily/emlop that referenced this issue May 6, 2022
* The API changes are a mixed bag but look good overall
* Had to swap the failure exit codes (as clap now `exit(1)` instead of 2)
  Keeping the old codes is possible, but doesn't seem worth the added complexity
  See clap-rs/clap#3426
* Stumbled upon one shell completion regression, so pining an old clap_complete version for now
  See clap-rs/clap#3697
* Subcommand completion no longer erroneously include `-V` and `--version`
* Help and diagnostic outputs seem a bit nicer
@OddBloke
Copy link

For anyone else who's wound up here, that example code has moved to: https://github.com/crate-ci/typos/blob/master/crates/typos-cli/src/bin/typos-cli/main.rs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this
Projects
None yet
Development

No branches or pull requests

3 participants