On 9/11/25 5:02 PM, Mike Jonkmans wrote:
Hi,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. Executing function `foo' doesn't save and restore BASH_COMMAND. The bash debugger, where BASH_COMMAND originated, established the semantics.
According to the trace, foo is not being run.
It has already completed execution by the time you generate the trace.
The ERR trap is not inherited (set -E/+E doesn't matter here).
'man bash' says: it is the command executing at the time of the trap.
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.
3) Couldn't BASH_COMMAND become an array?
How would that help?
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.
--
``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
