On Mon, Sep 15, 2025 at 04:25:07PM -0400, Chet Ramey wrote: > On 9/13/25 5:45 AM, Mike Jonkmans wrote: > > On Fri, Sep 12, 2025 at 04:31:07PM -0400, Chet Ramey wrote: > > > On 9/11/25 5:02 PM, Mike Jonkmans wrote: > > > > The below script echoes (when saved to bash_command.bash): > > > > Trace: > > > > 1: bash_command.bash:29 onerror () > > > > 2: bash_command.bash:29 mymain () > > > > 3: bash_command.bash:31 main () > > > > mymain: 29 status=1 command=return 1. > > > > > > > > 1) BASH_COMMAND is foo's 'return 1'. Shouldn't that be 'foo'? > > > > There is no error in 'return 1' per se. > > > It returns an error status, and it's the command that causes the ERR > > > trap to be run. So `return 1' executes, which sets BASH_COMMAND; it > > > completes (which causes `foo' to complete execution as a side effect); > > > and the ERR trap runs with BASH_COMMAND unchanged.
Upon re-reading this, I see that it is the same as what I describe below. The trap does spring only after foo completes in mymain. The BASH_COMMAND was sort of a red-herring to that. [ BTW. did you know that the Dutch eat their herrings raw?! ] > > Since -E/errtrace is not in effect, > > how can a command (i.c. return 1) in foo, cause the trap to spring? > > I am expecting the trap to spring in the context of the 'mymain' function, > > only *after* foo has ran to completion with a non-zero exit status. > I think it's reasonable to save and restore $BASH_COMMAND around function > execution. There's a little complexity associated with inheriting the ERR > trap and the return builtin (funny that, almost exactly the conditions in > your report) that I will have to think about. The current structure makes > it difficult to know when you want to save and restore BASH_COMMAND. That would be nice. As a side note to that quest. I am using the DEBUG trap in my PROMPT_COMMAND. Among other things, it shows BASH_COMMAND in the statusline of my tmux-pane. When I run a function, it shows the name of that function. Not sure if that helps with the ERR trap. Anyway, thanks for your patience and good work! -- Regards, Mike Jonkmans
