Like most customization and command replacements (like the fancy greps, ls's, etc), I've stopped using fancy prompts because I log in to lots of systems over the day and most of them won't have my prompt and this causes annoyance.

Also I have a theory that it lowers chatbot performance if you're copy pasting terminal output.

ty giles

Now this is prompt engineering.

My buddy spike723 on EFnet built what I can only describe as a sentinent bash prompt. I recall it being massive and could show you everything about your system in a prompt.

25 years later I have no clue where this guy went but I remember him because he was instrumental in moving me off zsh to bash

I find it’s very valuable to have a time Delta in the prompt. Knowing how long something normally takes can help you catch situations where your five second test run turns into a 30 second test run very easily.

Adopted:

  https://atuin.sh/
  https://github.com/akinomyoga/ble.sh
  https://starship.rs/

These three have made my shell game so much more enjoyable.

I strongly recommend against putting a ">" in your prompt on Unix if you're using any kind of system that supports copy and paste. (So, like, on a physical VT100 on a serial port it would be okay.) Sooner or later you're going to take a prompt-included command like

    > ls GN*

and accidentally paste it into a terminal window (or a web page that someone else pastes into a terminal window) and accidentally create an empty file named "ls". Or, in some cases, overwrite an existing file.

My own current setting is

    PS1=': ${env:+($env) }\W; '

Which looks like this:

    : ~; cd wak
    : wak; ls
    LICENSE   monosrc    scripts  toybox            toybox_awk_test
    Makefile  README.md  src      toybox_awk_parts
    : wak; 

The :; has the advantage that, if you unintentionally include the prompt in your copy and paste, it usually has no effect. (Maybe I should change ($env) to [$env].) \W (the last segment of the directory name) is usually about the right amount of context for me, but if I were working on a project with a lot of directories named things like "views" I would probably reconsider that.

BTW, since this prompt collection was written, Linux terminal emulators have mostly gained 24-bit color support, which potentially opens up more alternative colors. See http://canonical.org/~kragen/sw/dev3/gradient.c with sample results in http://canonical.org/~kragen/sw/dev3/gradient.png. The escape sequence is \033[38;2;rrr;ggg;bbbm, where \033 is ESC and rrr, ggg, and bbb are decimal numbers from 0 to 255.

(Probably I should switch from bash to zsh...)

  alias rm='/bin/rm -I'

    rm -rf * & cd; trn

    rm -rf * & cd; trn

  Do nothing beyond expanding arguments and performing 
  redirections. The return status is zero.

Missing from all of these: Error code returned from previous command. Invaluable.

I was a bit surprised only one of them included showing if the last command succeeded or not. My $ being green if ok red otherwise is one of the few things I miss when using a stock prompt.

For bash users I can recommend looking into setting PS1 from a function and assigning that function to PROMPT_COMMAND as it makes it much easier to make it readable

Another idea: an indication of how many background jobs are currently running. With many terminal tabs open, I can forget if I already have $EDITOR (or something else) running, so the number of jobs can be a nice cue.

    _jobscount() {
        local jobs=($(jobs -p))
        local count=${#jobs[@]}
        (($count)) && echo -n " (${count}j)"
    }

And then put that in your prompt.

you can spot a journey man by the lack of last command exit code on the bash prompt.