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

Migrate away from exitcode #177

Open
SUPERCILEX opened this issue Oct 4, 2022 · 9 comments
Open

Migrate away from exitcode #177

SUPERCILEX opened this issue Oct 4, 2022 · 9 comments
Labels
enhancement New feature or request

Comments

@SUPERCILEX
Copy link

See benwilber/exitcode#13 (comment)

@epage epage changed the title Recommend sysexits instead of exitcode Migrate away from exitcode Oct 4, 2022
@epage epage added the enhancement New feature or request label Oct 4, 2022
@epage
Copy link
Contributor

epage commented Oct 4, 2022

We are looking at our default recommendation being the proc-exit crate. I just updated it for the Termiantion crate and to better reflect the status of sysexits. We just need to update the book to use it.

@SUPERCILEX
Copy link
Author

Sounds good, but proc-exit is unnecessarily complicated and opinionated if all you want are the exit codes. sysexits should still at least be mentioned as a "here's the crate that just has exit codes if you want that" thing. BTW, sysexit and sysexits are different. Just want to make sure we're talking about the same thing.

@epage
Copy link
Contributor

epage commented Oct 4, 2022

Maybe but I disagree with the choice of sysexits

  • Use of enums makes it fairly restrictive unless you are using it only for cosntants. If you aren't using it for the type, the enum becomes a bit useless.
  • sysexits.h error codes aren't something to implicitly endorse

@SUPERCILEX
Copy link
Author

Use of enums makes it fairly restrictive unless you are using it only for constants. If you aren't using it for the type, the enum becomes a bit useless.

I'm not sure I understand. You can always just cast it to a u8 and then do whatever your want. Or convert it to std::process::ExitCode. Also, using it only for constants is kind of the point.

sysexits.h error codes aren't something to implicitly endorse

True but then why mention exitcode at all? Seems like a red herring argument.

@epage
Copy link
Contributor

epage commented Oct 4, 2022

True but then why mention exitcode at all? Seems like a red herring argument.

What does exitcode have to do with this?

@SUPERCILEX
Copy link
Author

What does exitcode have to do with this?

It's recommended here: https://rust-cli.github.io/book/in-depth/exit-code.html

@SUPERCILEX
Copy link
Author

Yeah actually let me just make a PR.

@epage
Copy link
Contributor

epage commented Oct 4, 2022

Yes and I have no problem removing exitcode in that document but it would be to replace it with proc-exit.

@SUPERCILEX
Copy link
Author

Hmmm, I just disagree. The opinionated thing should be in https://rust-cli.github.io/book/tutorial/errors.html whereas https://rust-cli.github.io/book/in-depth/exit-code.html should provide just the exit codes.

Or really, exit-code.html should be deleted in favor of an all-encompassing solution inside errors.html that is capable of returning arbitrary exit codes upon error. proc-exit does not address this use case. error-stack does, or anyhow with a custom error type that holds the exit code. Either way, all you need are the exit codes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants