Assorted TRAPxxx / trap xxx observations

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 27, 11:35am, Bart Schaefer wrote:
}
} ... they deliberately DID use the trap builtin when I added them, but
} it was determined that some side-effects didn't propagate correctly if
} functions were not used.

Incidentally, anonymous functions provide (inflict?) some interesting 
semantics for the "trap" command.

torch% unsetopt debug_before_cmd
torch% trap '() { print $LINENO $1 } $LINENO' DEBUG
0 2
torch% echo "What's my line?"   
What's my line?
0 3
torch% 

A couple of fun things there.

1. This is probably obvious, but it means you can get the benefits of a
separate function context in the trap without side-effect of the return
value acting as an interrupt.  Are there other non-obvious things?  Any
of this worth adding to the doc?

2. Installing a DEBUG trap with NODEBUG_BEFORE_CMD in effect causes the
setting of the trap to debug itself.

Regarding the return value acting as an interrupt, a nonzero return from
a DEBUG_BEFORE_CMD trap behaves exactly the same as "setopt ERR_EXIT" in
that it prevents the upcoming command from executing.  Either this is an
unintentional change, or we don't need the ERR_EXIT trick any more.

I also previously had not considered the interaction of $? with debug
traps, specifically DEBUG_BEFORE_CMD.  (Sorry, Peter, I'm about to make
your eyes glaze over, again.)  The upshot is that $? in the trap refers
to the previous command in one case, and to the command being debugged
in the second case.

torch% trap '() { print ERR $? }' ZERR
torch% trap '() { print DBG $? }' DEBUG
torch% false
DBG 0
ERR 1
torch% true
DBG 1
torch% unsetopt debugbeforecmd
DBG 0
torch% false
DBG 1
ERR 1
torch% true
DBG 0
torch% 

I suppose $? has to be the status of the previous command in the debug
trap when it runs before, because the upcoming command has to be able
to test the previous command's status.

Mostly this raises documentation issues.  It's not mentioned anywhere
that toggling DEBUG_BEFORE_CMD inside the trap will NOT cause the trap
to execute twice (something that might be interesting if you want to
examine $? both before and after).  It's also not explicitly called out
that the value of $? always refers to whatever executed right before
the trap, which differs with the state of DEBUG_BEFORE_CMD, but this may
be considered obvious.

That's all for now ...

-- 
Barton E. Schaefer