bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] trap -p does not display ignored signals inherited from pare


From: Chet Ramey
Subject: Re: [PATCH] trap -p does not display ignored signals inherited from parent by a bash process
Date: Fri, 26 Mar 2010 20:22:52 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

On 3/26/10 1:50 AM, Siddhesh Poyarekar wrote:
> On Fri, Mar 26, 2010 at 2:40 AM, Eric Blake <address@hidden> wrote:
>> Yes.  POSIX requires this for non-interactive shells, and does not
>> forbid it for interactive shells.  Technically, this code could be
>> modified to exempt interactive shells from hard-ignores, or left as is
>> by treating both classes of shells identically in keeping things
>> hard-ignored; either approach still meets POSIX.
>>
> 
> The code does explicitly hard ignore signals ignored when entering a
> non-interactive shell; see initialize_terminating_signals() in sig.c.

This isn't exactly true, but it doesn't really matter.

> The problem is that in addition to this, it ends up doing a hard
> ignore for the special signals in GETORIGSIG() -- not for all
> terminating signals, just the special signals.

This is true only for interactive shells.  It might be a useful addition,
and improve consistency, to set the original signal for terminating
signals when initialize_terminating_signals finds an ignored signal.
(It might be better to leave it ignored.  I'll think about it.)  Another
approach is to only set the hard-ignore flag in non-interactive shells.

Either way, you're right: the shell has to do something with signals it
catches, because the true inherited value has to be saved somewhere.
Other signals are already handled by the trap builtin, which does the
right thing.

I think this isn't a big problem.  Bash is allowed to completely disregard
signals that are ignored when it is invoked.  It doesn't matter what it
does internally, as long as it obeys the Posix rules: don't allow the
disposition to be manipulated with trap when the shell is not interactive,
and make sure that child processes have the signal handlers set correctly.

This discussion did allow me to find and fix one bug: interactive shells
did not reset the handlers for terminating signals correctly when
running commands from the file system.  That fix will be in the next
bash release.

> What's more, BeOS gets special treatment in all this; its hard ignore
> flag is removed after GETORIGSIG() for SIGINT because BeOS sets SIGINT
> to SIG_IGN by default:

Yes.  Both BeOS systems still running need it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]