Luke Boswell (Jun 22 2023 at 09:15): Luke Boswell (Jun 22 2023 at 09:15):I've noticed the docs in std::process::Command for getting the exit status code produces a signed integer. We recently updated basic-cli to use an unsigned U32 failure value for main. It would be nice if running commands was able to produce the same error/fail type as this would make things much more "seamless" when using the Command module tasks within main.
Is there any reason we chose unsigned over signed? Does it make sense to change to main : Task {} I32 instead?
pub fn code(&self) -> Option<i32>
Returns the exit code of the process, if any.
In Unix terms the return value is the exit status: the value passed to exit, if the process finished by calling exit. Note that on Unix the exit status is truncated to 8 bits, and that values that didn’t come from a program’s call to exit may be invented by the runtime system (often, for example, 255, 254, 127 or 126).
On Unix, this will return None if the process was terminated by a signal. ExitStatusExt is an extension trait for extracting any such signal, and other details, from the ExitStatus.
I also thought I might see what ChatGPT had to say about the issue.
In general, programs can return both positive and negative values as exit codes. Conventionally, an exit code of 0 is used to indicate a successful execution or termination of a program. Positive exit codes are often used to represent various success or informational states, depending on the program's specific requirements or conventions.
Negative exit codes, on the other hand, are typically used to indicate errors or exceptional conditions. However, the interpretation and specific meaning of negative exit codes are program-dependent. Some programs may define specific negative values to represent different types of errors or failure scenarios, while others may not use negative exit codes at all.
Richard Feldman (Jun 22 2023 at 10:07):interesting! I'm up for changing it to I32 :thumbs_up:
Luke Boswell (Jun 23 2023 at 03:22):Submitted PR #65 for this change. Note I think the two PR's will likely conflict, happy to merge main and update if/when required.
Last updated: Jul 26 2025 at 12:14 UTC