On 03/03/19 16:07, Pádraig Brady wrote:
> On 03/03/19 15:36, Pádraig Brady wrote:
>> On 25/02/19 22:35, Pádraig Brady wrote:
>>> Thanks for doing all that.
>>> I've attached a few changes:
>>>
>>> - spelling fixes
>>> - usage() clarified/reordered
>>> - ensure sigset_t are initialized
>>> - Don't setprocmask() unless specified
>>> - Simplified SETMASK_SIGNAL_OPTION handling
>>> - The test missed `env` as a prerequisite
>>> - The test was slow/spun cpu, so used sleep instead of seq
>>> - Used $SHELL in case sh didn't support trap
>>>
>>> I see that the last signal that `kill -l` lists is not included.
>>> I think we should be processing SIGNUM_BOUND also?
>>
>> An additional patch attached to replace --list-signal-actions
>> with --list-ignored-signals.  This is simpler, and more symmetric
>> with the other options. Also the extra output was moot I think
>> since handlers are reset upon exec
> 
> I've locally adjusted the NEWS/texi for that patch also.
> I've a local patch to include SIGNUM_BOUND which I won't spam the list with.
> 
> Attached is a patch to remove the -p and --set-mask options,
> which I've a light preference for.
> I'll think some more about it.

Attached is a patch to combine the two --list options
to a single --list-signal-handling option.
This also doesn't exit, and so is more useful as
users can add --list-signal to their env commands
to diagnose signal handling.  One can easily use `true`
as the command to get the original list only functionality.

A summary of the all signal options in my local set now is:

  --block-signal[=SIG]    block delivery of SIG signal(s) to COMMAND
  --unblock-signal[=SIG]  unblock delivery of SIG signal(s) to COMMAND
  --default-signal[=SIG]  reset handling of SIG signal(s) to the default
  --ignore-signal[=SIG]   set handling of SIG signals(s) to do nothing
  --list-signal-handling  list non default signal handling to stderr

cheers,
Pádraig