Support `cmd_duration` robustly in bash about starship HOT 4 CLOSED

Comments from code:

 For bash: we need to manually hook functions ourself: PROMPT_COMMAND will exec
   right before the prompt is drawn, and any function trapped by DEBUG will exec
   before a command is run. There is no way to avoid clobbering these functions,
   so we will not hook them if they are already defined.

   There is a preexec/precmd framework for bash out there: if we find the
   appropriate variables set, assume we are using that framework:
   https://github.com/rcaloras/bash-preexec

   Bash quirk: DEBUG is triggered whenever a command is executed, even if that
   command is part of a pipeline. To avoid only timing the last part of a pipeline,
   we only start the timer if no timer has been started since the last prompt draw,
   tracked by the variable PREEXEC_READY. Similarly, only draw timing info if
   STARSHIP_START_TIME is defined, in case preexec was interrupted.

   Finally, note that `eval` will evaluate this thing as a single line, so things
   like comments (#) should be avoided and semicolons should be used on most
   statements (but not after then/else).

from starship.

Possible solution: hackily glue on an additional function to the debug trap.

For example, if the function sugar is currently bound to the debug trap, we can do

function newTrapFunc(){ starship_preexec; sugar; }
trap newTrapFunc DEBUG

and now the DEBUG trap triggers newTrapFunc, which in turn triggers both our preexec function and the old trap function.

This isn't 100% robust, but given that all prexec frameworks in bash seem at least a little janky, this might be an acceptable solution.

We do need to potentially worry about changing the environment in which the old trapped function will run (e.g. we might change the value of $? by running our preexec function). Maybe we should run our preexec last, after the other functions have run? This risks affecting the timing slightly, but I don't think DEBUG-trapped functions should take that long to run...

from starship.

I think this sounds like a pretty solid solution. I haven't worked before with DEBUG trap triggers, so I can't really challenge your solution. 😛
Would it be difficult to create a proof-of-concept for this implementation?

from starship.

POC code: https://github.com/chipbuster/starship/tree/bashtimer

Interesting notes: the old trapped function now fires multiple times because the commands being used in PROMPT_COMMAND are triggering it as well.

As far as I can tell, this is actually correct behavior, since DEBUG isn't really intended to be a preexec-like--it's intended to fire every time a command is called. When using it to time commands, you only want it to fire once per prompt cycle (we're currently doing that with a rather tricky dance of variables being set/unset), but the actual underlying DEBUG trap should fire every time a command is run (even if that's in the context of setting up the prompt).

I think this is arguably correct behavior, but it might be a little unexpected, so we should probably put a note in the docs (maybe in that warning section for cmd_duration that behavior around pre-existing DEBUG traps may be surprising, since we use a lot of external commands to set up the prompt.

from starship.