On 9/13/25 5:45 AM, Mike Jonkmans wrote:
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.
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.
Aha, too late for that. What are these semantics? Does BASH_COMMAND only hold simple commands?
No, but usually the debugger is executing simple commands, so it's the most common case. It also contains, for example, (( commands, [[ commands, (subshells), and arithmetic for commands.
3) Couldn't BASH_COMMAND become an array?How would that help?It could track the commands leading upto the current one.
This really only matters on function calls, and I think it's too much overhead.
This is overhead, so would be feasible only, if computed on demand or behind extdebug.
No, you'd have to maintain the information somewhere in another call stack, so there's no `computing on demand'.
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.
Again, there is no `computing on demand' here. You have to save the
information in order to return it. And if you want to save the data
only when extdebug is set, there's no difference between that and
BASH_ARGV.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
