New exit status for rustup check can feel confusing to interactive users #4681
Description
(Originally posted as https://internals.rust-lang.org/t/seeking-beta-testers-for-rustup-v1-29-0/23814/3)
Testing the new beta, I found the exit code of rustup check a bit confusing.
The previous behavior is such that if everything is up to date, all output is green, and if it isn’t there are yellow “Update available” lines.
So much is unchanged… but now we also get an exit code indicating the overall result…
…but that exit code is just feeling very the wrong way around:
- all is green "Up to date" ✅
- overall exit code: 1 error ❌
- some yellow "Update available"
⚠️ [possibly also some green "Up to date" ✅]- overall exit code: 0 success ✅
The change was introduced in #4340, where the main motivation appears to be usage in some custom minimal interface on top of rustup; using this exit code as a way to check if something can be updated before then prompting the user with the question of if they want to update.
For this specific use-case, it seems plausible that success is "updates are available", and anything else ("all up to date" or "some error occurred") is kind-of the same thing, since it means, rustup can’t do any updates right now (either because everything is up to date, or because some other erroneous condition is present – like what acutally 🤔? no network, for example, perhaps?)
OTOH, rustup check was first introduced rather for interactive use, so I’d like that not to become any more confusing… as someone who has their terminal promt set up in such a way that nonzero exit codes do display as red :X: marks, I find it a bit weird this way around, as explained in the previous section.
I have not yet found good prior art for any comparable commands of similar tools. One thing I have noticed though is that a 3-way distinction of exit codes might be worth considering in any case, so that users can – if they want to – cleanly differentiate two "successful" cases of "rustup check has determined whether updates are available" from the case of "any other errors happened". This way, a script that only wants to act on the "updates are available" case, can still pick out that one, even we choose the exit code 0 to be for "everything is up to date".
Now I’m also noticing that rustup unconventionally uses exit code 1 instead of 2 for cases of incorrect command line arguments.
Anyway; one point of comparison for a 3-way distinction that i could find is ripgrep, which appears to produce 0 if matches are found, 1 if no matches are found, and 2 for any other error (incorrect command line arguments or wrong regex syntax for sure; but I also tried e.g. having a file without read permissions).
Another idea, if "updates are available" stays the success case, could be to change the color coding. For example, "up to date" could become bold(?) white text, and "update available" bold(?) green.
Yet another (probably too “creative” though(?)) idea could be to leave the exit value always at 0 once again, but instead split the output between stderr (for the up to date kind of messages) and stdout (for the update available kind of messages), so a script could choose to inspect only stdout if it wants to know if and how many updates are available (by counting the lines of stdout).
I do acknowledge that this is slightly further complicated by the new parallelized checking & output, though I would have ideas on how to make that still properly anyway.