Added exit code support

[twolfson]

As per #82, we've wanted exit code support for a while and are finally adding it

We discovered the quirk that bash will persist exit codes until a new command is provided so we added a configuration to ignore that

In this PR:

• Added non-zero exit code support
• Added tests
• Added PROMPT_SYMBOL_ERROR_COLOR environment variable support for customization
• Added PROMPT_SHOW_ERROR_ONCE environment variable to allow opt-out of hiding persisted exit code
• Added documentation
• Depends on #88, don't land until that's landed (and then update this PR base to master)

Screenshots:

[twolfson]

@rpdelaney I think this was missed while reviewing #88 as well =/

[rpdelaney]

I saw it. It's looks a bit more complex so I'm waiting until the end of my work day so I can put some more time into looking at it.

[twolfson]

Ah, gotcha. Sounds great. Thanks for your help as always @rpdelaney =)

[twolfson]

Hmm, what's confusing about PROMPT_SHOW_ERROR_ONCE? The scenario it's solving for? Implementation? Something else?

[twolfson]

Deciding to land for now, hopefully we can iterate on clarity in a future PR

[twolfson]

Oh damn it, I forgot to update the base -_-;; Going to see if I can just cherry-pick to master anyway =/

[rpdelaney]

I think I understand what the code is doing more than I understand why it's doing it :)

[twolfson]

:+1: Alright, really verbose explanation of all the scenarios and how we fix them:

Blank terminal

• Open a new terminal
• Exit code is 0 by default
• We display a white $
• We press enter (no new command a few times)
• Exit code is still 0 so we keep displaying a white $
• Nothing unexpected here

Successful exit code

• Open a new terminal
• Execute a successful command (e.g. true)
• Exit code is 0
• We display a white $
• We press enter (no new command a few times)
• Exit code is still 0 so we keep displaying a white $
• Nothing unexpected here

Non-zero exit code

• Open a new terminal
• Execute a successful command (e.g. false)
• Exit code is non-zero (e.g. 1)
• We display a red $
• We press enter (no new command a few times)
• Expected behavior (for me at least)
  • Blank command is interpreted as a new command
  • Exit code is set to 0
  • We display a white $
• Actual behavior
  • Bash doesn't reset exit code on blank command
  • Exit code is still non-zero so we keep displaying a red $

Keyboard interrupt

• Open a new terminal
• Start typing a valid command but run keyboard interrupt instead (Ctrl+C)
• Expected behavior (for me at least)
  • We can potentially identify this as a zero/non-zero exit code, I'm fine with either scenario
  • but the next lines matter...
  • We press enter (no new command a few times)
  • Blank command is interpreted as a new command
  • Exit code is set to 0
  • We display a white $
• Actual behavior
  • Exit code is non-zero (i.e. 130)
  • We display a red $
  • We press enter (no new command a few times)
  • Bash doesn't reset exit code on blank command
  • Exit code is still non-zero (i.e. 130) so we keep displaying a red $

What our fix does

• Updates behavior to detect when a blank command is entered
  • i.e. A valid command would have a new history entry
  • A blank command wouldn't be input in the history
  • As a result, if we see the same timestamp+command in history then we know it was a blank command
• When a blank command is entered, then reset the exit code to our expected behavior

Does that clear things up? Is this good enough to link to in the code comments for a verbose explanation?

[twolfson]

Want to add that I've realized my dotfiles has a HISTTIMEFORMAT setting in it which causes a timestamp in my history:

  499  2020-09-07T20:23:57-0700 false
  500  2020-09-07T20:23:57-0700 false
  501  2020-09-07T20:23:58-0700 history 5

The history check still works regardless though as we have the history number in each prompt (i.e. 500/501/etc):

  500  false
  501  history 5
  502  history 5