Tracking issue for std::process::ExitCode (feature process_exitcode_placeholder)

[scottmcm]

https://doc.rust-lang.org/nightly/std/process/struct.ExitCode.html

Code added in #48497 (comment); changed to this issue in #48618
Creating this because ?-in-main (#43301) will probably stabilize first

This is very minimal so far, and hasn't had an RFC. IRLO thread for what it should be.

Unresolved Questions

• @yaahc: Should we impl PartialEq or add is_success()/is_failure() methods to ExitCode? Brought up in Change Termination::report return type to ExitCode #93442 (comment) and in the resolved comment thread initiated by @scottmcm in that same thread

[yoshuawuyts]

From discussions we've had in the WG-CLI gitter, something that would be amazing to have would be a way to enumerate all possible exit codes for a program.

We're currently looking into automatically creating man pages for CLIs, and being able to automatically document which exit codes are possible would let Rust do something that no other language does.

I don't have any proposals on how to best approach this, but figured it would probably be worth bringing up.

Thanks!

edit: PS. I hope this is the right thread to mention this in! Apologies if I got it wrong!

[scottmcm]

@yoshuawuyts Sounds like a cool feature! I don't know if this struct is exactly the thing you'd need, though, since it'll probably just remain a newtype. Maybe you could have a custom derive to generate Termination or Into<ExitCode> on an enum where the variants are the possible codes, as a place to put the numbers and documentation about them, and still use in the code?

[raphaelcohn]

Would you consider also adding the definitions from sysexits.h, which are commonly used by mail programs (eg postfix) amongst others?

For example:-

#define EX_USAGE 64
#define EX_DATAERR 65
#define EX_NOINPUT 66
#define EX_NOUSER 67
#define EX_NOHOST 68
#define EX_UNAVAILABLE 69
#define EX_SOFTWARE 70

See https://github.com/bminor/musl/blob/master/include/sysexits.h for a full list. All part of any POSIX libc.

In particular, it'd be nice if an uncaught panic resulted in an exit code of EX_SOFTWARE on POSIX systems rather than EXIT_FAILURE...

[scottmcm]

@raphaelcohn The design space here is still wide open, so it's certainly possible. There are some thoughts in the IRLO thread, but really it needs someone to dig in and make a proposal.

As for uncaught panics, I believe they currently give a 101 exit code, not EXIT_FAILURE.

[JoshMcguigan]

...something that would be amazing to have would be a way to enumerate all possible exit codes for a program... currently looking into automatically creating man pages for CLIs

@yoshuawuyts Has any progress been made on this? I'm wondering if https://github.com/JoshMcguigan/exit could be expanded or somehow tied into some broader cli library to solve this problem?

[yoshuawuyts]

@JoshMcguigan hey, thanks for asking! I read your blog post, and I really like the work you've been doing!

To answer your question: man now supports defining custom exit codes. However we haven't created any sort of bridge (e.g. the closest we've come is to create a bridge to clap).

That said, I do have some thoughts on this. I was chatting with @davidbarsky last week about the failure crate, and the exitfailure crate came up. This fills a similar program slot as exit, but does a slightly different job.

It's worth mentioning that at the Rust all-hands there was talk about moving error chains (.context()) into stdlib. Unless anything has changed in the past week, it seems likely there'll be an RFC for this.

I'm wondering if we could somehow merge all of these features into a single crate, and find a solution that works for most people. The features I'm currently thinking of are:

• be able to define custom exit codes, with a reason
• be able to use use pre-defined exit codes (e.g. from the exitcode crate, + exit code 101 for Rust panics).
• log a list of causes using the log crate on error. (similar to exitfailure, but without writing directly to stdout.)
• be able to define these exit statuses in a separate struct, so it can be exported as a man page in a build.rs script without needing to do a double compile of all of the code.

---

Haha, I hope all this makes sense. Sorry it's a lot of text; it's something I've been thinking about for a few months, but didn't quite get a chance to connect all pieces until now. I hope this is useful!

[bazaah]

I'm not sure if this or the ?-in-main thread is the correct venue for my question, so feel free to slap me if this is the wrong place.

I'm curious what needs doing before I can return an arbitrary exit code (between 1-127) from main using ? in main on stable. I currently do this on nightly by implementing Try + Termination on an enum that is basically a specialized Option where T: From<i32> + Error, with None representing a successful program exit.

I've read most of the links in #43301 and the preRFC but am still uncertain about status of my need, or how go about implementing it.