Thanks for your answers.
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.
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.
Maybe I am misunderstanding something (not unlikely).
> Executing function `foo' doesn't save and restore BASH_COMMAND. The bash
> debugger, where BASH_COMMAND originated, established the semantics.
Aha, too late for that.
What are these semantics? Does BASH_COMMAND only hold simple commands?
[ I am not familiar with the bash debugger - never needed to.
Using old school echo/printf, since the PDP-11, teletype days :) ]
> > According to the trace, foo is not being run.
> It has already completed execution by the time you generate the trace.
Seemingly so. Though if, as you say, foo's 'return 1' causes the ERR trap
to be run, then as the stacktrace is printed from that,
one would expect foo in the stacktrace.
> > 2) Why use 'main' as toplevel function?
> It's a default. I thought it was better than other alternatives, back in
> 2003.
> > Would rather have the empty string here. Is that (still) possible?
> I don't think so; we have over 20 years of backwards compatibility to
> consider.
Agreed. Too little gain for the trouble.
> > 3) Couldn't BASH_COMMAND become an array?
> How would that help?
It could track the commands leading upto the current one.
In this case it might be ( 'return 1' foo mymain main )
Which is different from ( "$BASH_COMMAND" "${FUNCNAME[@]}" )
in that it also would have "$@" added to each FUNCNAME.
This is overhead, so would be feasible only, if computed on demand
or behind extdebug.
(As $BASH_COMMAND == ${BASH_COMMAND[0]}, it seems mostly backwards compatible).
> > 4) Would FUNCARGS[] be an addition?
> > Holding the actual expanded arguments to the corresponding FUNCNAME.
> That seems like a lot of overhead for not much functionality beyond what
> BASH_ARGV provides. If you want to use BASH_ARGV, turn on extdebug.
Feasible only, if it could be computed on demand or behind extdebug.
Unfortunately, BASH_ARGV/extdebug is not so useful in printing the stacktrace
from an ERR trap.
[ Using extdebug, leads to the question of where/when to set it.
Unconditionally would always incur the overhead.
Inside the trap is too late. ]
--
Regards, Mike Jonkmans
