Re: Differences between "TRAPERR()" and "trap foo ERR"

[Zach Riggle <zachriggle@xxxxxxxxx>]

Thanks for the quick response, Bart!

> The signal number will be passed as the first parameter to the function.

Wow, I am dense and poor at reading documentation.  Thanks for
pointing out the relevant portion to me.

> The TRAPnal form and the argument it receives are a zsh extension.

Welp, that explains the rest of it!

> You might also read about the POSIX_TRAPS and LOCAL_TRAPS setopts.

Thanks, I will definitely look up the docs for this.

Humbled and appreciative,
Zach Riggle

On Wed, Jul 28, 2021 at 12:00 AM Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 27, 2021 at 8:47 PM Zach Riggle <zachriggle@xxxxxxxxx> wrote:
> >
> > Overall, there are two observations.
> >
> > 1. The behavior that TRAPNAL will receive NAL as its first argument,
> > where NAL corresponds to a the system-defined signal values (e.g.
> > SIGSEGV == 11).  The name for this signal can be gotten from
> > ${signals[x+1]}.  This should be documented.
>
> 9.3.2 Trap Functions:
>
> TRAPNAL
>      If defined and non-null, this function will be executed whenever
>      the shell catches a signal SIGNAL, where NAL is a signal name as
>      specified for the kill builtin.  The signal number will be passed
>      as the first parameter to the function.
>
> > 2. This behavior does not expand to "trap func NAL" statements, even
> > if we try to pass "$@" to some function.  This seems like a bug.
>
> It's not a bug; it's the normal behavior of the "trap" in the shell
> language.  The TRAPnal form and the argument it receives are a zsh
> extension.
>
> The "trap" builtin takes an arbitrary list of commands rather than a
> function body.  There is therefore no "argument list" where the signal
> number can be passed.  If you write
>
>   trap 'echo in a trap' USR2
>   functions
>
> you will see that there is no TRAPUSR2 function created.  "unfunction
> TRAPUSR2" removes the USR2 trap as a side-effect, but also complains
> "no such hash table element".  That's a bit of an oddity, but is in
> part why the doc for the "trap" builtin says:
>
>      Defining a trap under either name causes any trap under an
>      alternative name to be removed.  However, it is recommended that
>      for consistency users stick exclusively to one name or another.
>
> Other distinctions considered important are also mentioned there:
>
>      Note that traps defined with the trap builtin are slightly
>      different from those defined as 'TRAPNAL () { ...  }', as the
>      latter have their own function environment (line numbers, local
>      variables, etc.)  while the former use the environment of the
>      command in which they were called.  For example,
>
>           trap 'print $LINENO' DEBUG
>
>      will print the line number of a command executed after it has run,
>      while
>
>           TRAPDEBUG() { print $LINENO; }
>
>      will always print the number zero.
>
> You might also read about the POSIX_TRAPS and LOCAL_TRAPS setopts.