From: Zach Riggle <zachriggle@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: Differences between "TRAPERR()" and "trap foo ERR"
Date: Wed, 28 Jul 2021 00:04:51 -0500 [thread overview]
Message-ID: <CAMP9c5nSV-u1CVXCE1vbnXC_TysaU0FKm1omKNiMhq8dvRbUUw@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7bP3d+Ju12+73DJpfEOjj+nsRctd75b=YcMC7k8w=19hw@mail.gmail.com>
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@brasslantern.com> wrote:
>
> On Tue, Jul 27, 2021 at 8:47 PM Zach Riggle <zachriggle@gmail.com> 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.
prev parent reply other threads:[~2021-07-28 5:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-28 3:47 Zach Riggle
2021-07-28 5:00 ` Bart Schaefer
2021-07-28 5:04 ` Zach Riggle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMP9c5nSV-u1CVXCE1vbnXC_TysaU0FKm1omKNiMhq8dvRbUUw@mail.gmail.com \
--to=zachriggle@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).