Re: [PATCH] trap -p does not display ignored signals inherited from parent by a bash process

[Eric Blake]

[please keep the list in the loop]

On 03/25/2010 12:20 AM, Siddhesh Poyarekar wrote:
> On Tue, Mar 23, 2010 at 9:30 PM, Siddhesh Poyarekar
> <siddhesh.poyarekar@gmail.com> wrote:
>>> I see no bug - bash is within its rights to pretend that an inherited
>>> ignored SIGINT has no trap setting, seeing as how the user cannot modify
>>> that through any use of trap.  That is, 'trap -p' is designed to output
>>> the text that will restore traps to their normal state, but since there
>>> is no way to change the state of SIGINT from being ignored, there is
>>> nothing needed in the output.
>>>
>>
>> Thanks for that explanation. I guess we can also detect if a signal is
>> being ignored by trying to set a trap for that signal and verify that
>> it has not been set. This was my original problem and I went about
>> trying to fix it in code rather than reading the docs carefully :)
>>
> 
> I was wondering if this could be added as a feature to the trap
> behaviour, perhaps a non-standard extension like 'trap -i' which lists
> ignored signals. If not, we could modify the manpage contents to read
> as:
> 
> "Signals ignored upon entry to the shell cannot be trapped, reset or listed."
> 
> so as to make this even clearer.

Technically, this is only a POSIX requirement on non-interactive shells.
 Interactive shells may reset ignored signals on entry, effectively
starting life as if nothing had been inherited ignored.  But I don't
know (without looking at the sources) whether bash explicitly modifies
inherited ignored signals in interactive shells.

> 
> I'm asking this because I have a query from a customer (I work in Red
> Hat Support: <spoyarek@redhat.com>) for this and I had originally
> written the patch for RHEL-5. I've already let him know that the patch
> in the original form has been rejected and he has reverted with these
> questions.

I'm not the bash maintainer.  It's up to Chet if he'd like to provide
such an extension in the upstream sources.  But the beauty of open
source is that you can use your patch, whether or not Chet applies it
upstream; it's just that it becomes more of a maintenance burden on you
if you have to maintain it as a fork.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature