Suppose you do:

handler() { ... }
trap handler INT QUIT

Any collection of signals would work; I am using INT and QUIT here for
convenience.

The point is that you have one handler for both (i.e., all of the) signals,
and you'd like to be able to distinguish, inside of handler(), which signal
you are handling. You'd like for there to be some variable that holds the
signal number.

In C, this is straightforward. It seems like it should be so in shell as
well, but I could not find anything in the man page about it.

Note: I'm specifically interested in bash, but would be interested to read
about any other shell(s) that readers have used.

--
The scent of awk programmers is a lot more attractive to women than
the scent of perl programmers.

(Mike Brennan, quoted in the "GAWK" manual)

In article <sak25t$2d07d$2@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>Suppose you do:
>
>handler() { ... }
>trap handler INT QUIT
>
>Any collection of signals would work; I am using INT and QUIT here for
>convenience.
>
>The point is that you have one handler for both (i.e., all of the) signals,
>and you'd like to be able to distinguish, inside of handler(), which signal
>you are handling. You'd like for there to be some variable that holds the
>signal number.

This has been discussed in the POSIX standardization, but there is currently
no enhancement request.

Recent versions of the Bourne Shell (bosh) since summer 2015 set
${.sh.signame} while excuting the trap handler.

This was part of the conversions to use waitid() from 1988 instead of the
historical wait() call in order to be able to support all 32 bits from the
exit code of programs.

--
EMail:joerg@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

In article <sakm7e$nn8$1@news.dns-netz.com>, <joerg@schily.net> wrote:
>In article <sak25t$2d07d$2@news.xmission.com>,
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>Suppose you do:
>>
>>handler() { ... }
>>trap handler INT QUIT
>>
>>Any collection of signals would work; I am using INT and QUIT here for
>>convenience.
>>
>>The point is that you have one handler for both (i.e., all of the) signals,
>>and you'd like to be able to distinguish, inside of handler(), which signal
>>you are handling. You'd like for there to be some variable that holds the
>>signal number.
>
>This has been discussed in the POSIX standardization, but there is currently
>no enhancement request.
>
>Recent versions of the Bourne Shell (bosh) since summer 2015 set
>${.sh.signame} while excuting the trap handler.
>
>This was part of the conversions to use waitid() from 1988 instead of the
>historical wait() call in order to be able to support all 32 bits from the
>exit code of programs.

Very interesting. Thanks.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/WeekendAwayFromHome

On 6/19/2021 6:59 AM, joerg@schily.net wrote:
> In article <sak25t$2d07d$2@news.xmission.com>,
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> Suppose you do:
>>
>> handler() { ... }
>> trap handler INT QUIT
>>
>> Any collection of signals would work; I am using INT and QUIT here for
>> convenience.
>>
>> The point is that you have one handler for both (i.e., all of the) signals,
>> and you'd like to be able to distinguish, inside of handler(), which signal
>> you are handling. You'd like for there to be some variable that holds the
>> signal number.

It just takes one small function to implement it yourself:

--------
trap_handler() {
printf 'handling signal %s\n' "$1"
....
}

set_traps() {
for sig; do
trap "trap_handler $sig" "$sig"
done
}

set_traps INT QUIT
--------

Massage to suit wrt whether or not to pass the handler name as an
argument to set_traps and whether to define set_traps within your script
or externally, e.g. in .profile.

Regards,

Ed.

On 19.06.2021 08:17, Kenny McCormack wrote:
> Suppose you do:
>
> handler() { ... }
> trap handler INT QUIT
>
> Any collection of signals would work; I am using INT and QUIT here for
> convenience.
>
> The point is that you have one handler for both (i.e., all of the) signals,
> and you'd like to be able to distinguish, inside of handler(), which signal
> you are handling. You'd like for there to be some variable that holds the
> signal number.

I don't know any feature or straightforward workaround to achieve
that with the prominent shells.

I observe - correct me if I am wrong - and want to note that this
would require some decision making in the handler function, like

case $1 in ## just an informal use of $1
(INT) echo processing INT ;;
(QUIT) echo processing QUIT ;;
(*) echo huh ;;
esac

thus explicitly enumerating the signals (all of them or a desired
subset). This appears to me to be an inherent suboptimal approach.
When might that have positive aspects? Maybe if we build subsets?

case $1 in
(INT|QUIT) echo processing type A ;;
(HUP|TERM) echo processing type B ;;
(*) echo huh ;;
esac

Is there an advantage to

trap process_handler_A INT QUIT
trap process_handler_B HUP TERM

We can think of common (complex) code passages that we want coded
just once (not repeated in every trap handler), but we can rely on
a separate common function to achieve that.

Of course we could also add auxiliary shell code to pass the signal
name to the trap handler function (supporting syntactic sugar here)

mytrap() {
for t do
trap "handle $t" $t
done
}

mytrap INT QUIT

or slightly adjust the mytrap code to support

mytrap handler INT QUIT

So, while the feature appeared potentially useful to me at first,
I'm now after pondering about it not sure in which cases it actually
has any (or even a significant) gain.

Can you provide an example or application cases to make the advantage
of such a feature more obvious?

Janis

> [...]

On 2021-06-19, Ed Morton <mortonspam@gmail.com> wrote:
> On 6/19/2021 6:59 AM, joerg@schily.net wrote:
>> In article <sak25t$2d07d$2@news.xmission.com>,
>> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> Suppose you do:
>>>
>>> handler() { ... }
>>> trap handler INT QUIT
>>>
>>> Any collection of signals would work; I am using INT and QUIT here for
>>> convenience.
>>>
>>> The point is that you have one handler for both (i.e., all of the) signals,
>>> and you'd like to be able to distinguish, inside of handler(), which signal
>>> you are handling. You'd like for there to be some variable that holds the
>>> signal number.
>
> It just takes one small function to implement it yourself:
>
> --------
> trap_handler() {
> printf 'handling signal %s\n' "$1"
> ....
> }
>
> set_traps() {
> for sig; do
> trap "trap_handler $sig" "$sig"
> done
> }

Good call.

The trap handler is a full command, not simply the name of a function,
and that command can bind a function to whatever captured arguments
it needs.

It's like partial function application that is entirely based on
character strings.

(Note that lambda calculus can be implemented using manipulation of
purely textual formulas represented as character strings, at least if
restricted to eager evaluation.)

Kaz Kylheku <563-365-8930@kylheku.com> writes:

> On 2021-06-19, Ed Morton <mortonspam@gmail.com> wrote:
>> On 6/19/2021 6:59 AM, joerg@schily.net wrote:
>>> In article <sak25t$2d07d$2@news.xmission.com>,
>>> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>> Suppose you do:
>>>>
>>>> handler() { ... }
>>>> trap handler INT QUIT
>>>>
>>>> Any collection of signals would work; I am using INT and QUIT here for
>>>> convenience.
>>>>
>>>> The point is that you have one handler for both (i.e., all of the) signals,
>>>> and you'd like to be able to distinguish, inside of handler(), which signal
>>>> you are handling. You'd like for there to be some variable that holds the
>>>> signal number.
>>
>> It just takes one small function to implement it yourself:
>>
>> --------
>> trap_handler() {
>> printf 'handling signal %s\n' "$1"
>> ....
>> }
>>
>> set_traps() {
>> for sig; do
>> trap "trap_handler $sig" "$sig"
>> done
>> }
>
> Good call.
>
> The trap handler is a full command, not simply the name of a function,
> and that command can bind a function to whatever captured arguments
> it needs.

Yes, and you can use the command to set a variable if that is more
convenient:

trap "MySIGNAME=$sig trap_handler" "$sig"

--
Ben.

In article <87lf75fum2.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
....
>Yes, and you can use the command to set a variable if that is more
>convenient:
>
> trap "MySIGNAME=$sig trap_handler" "$sig"

There seem to be endless workarounds, but no actual solution.

I'm OK with that.

--
In American politics, there are two things you just don't f*ck with:

1) Goldman Sachs
2) The military/industrial complex

On 2021-06-19, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <87lf75fum2.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> ...
>>Yes, and you can use the command to set a variable if that is more
>>convenient:
>>
>> trap "MySIGNAME=$sig trap_handler" "$sig"
>
> There seem to be endless workarounds, but no actual solution.

Why are the suggestions "workarounds" rather than "solutions". What is
the difference between a workaround and a solution?
>
> I'm OK with that.
>