As a counterpoint, one of the most useful customizations I've made to my prompt is to emit the exit status of the prior command. Knowing that something failed is a useful signal, esp. when sometimes the thing failing just fails to emit any output that indicates that it failed.
I only emit it if the prior command fails, too, so it doesn't clutter things the 90% of the time things are working.
» true
» false
(last command returned 1.)
»
I also translate signals, so I get "last command exited on SIGSEGV", or so.
It's also useful the other way: when a program emits and error and exits with "success".
I think (if I am reading TFA's code right) unlike the article, I'm using zsh's module functionality, so the Rust here is a .so that is loaded directly into the shell's memory. (I.e., I do not have to fork/exec a separate Rust bin to compute the prompt, though I think zsh might fork-but-not-exec for computing the prompt itself.)
The latter is, of course, somewhat more complicated in some senses. (Esp. on macOS, which work forces me to use, where dlopen(2) is just utterly insane.)
In bash, it's enough to remember that $? expands to the exit code of the previous command, and $((x)) evaluate x as an integer expression, including the ternary operator x?y:z.
For example the following prints the exit code in green if zero, in red otherwise:
I like the exit code feature a lot; Starship does that with my config in a subtle color change.
My shell customization is largely throwing Starship in (so it looks the same on all the machines I use -- Ubuntu servers at work, macOS at home, nixOS/Fedora/etc. servers for personal use.) and a starship.toml I wrote once and now leave alone.
I only emit it if the prior command fails, too, so it doesn't clutter things the 90% of the time things are working.
I also translate signals, so I get "last command exited on SIGSEGV", or so.It's also useful the other way: when a program emits and error and exits with "success".