help-bash
[Top][All Lists]
Advanced

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

Re: [Help-bash] Bash is setting disposition of a signal, ignored upon en


From: Chet Ramey
Subject: Re: [Help-bash] Bash is setting disposition of a signal, ignored upon entry to shell, to default
Date: Thu, 10 Jan 2013 11:42:33 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 1/9/13 4:09 PM, Anoop Sharma wrote:
> Using: GNU bash, version 4.2.24(1)-release (i686-pc-linux-gnu)
> 
> I ignore a signal using trap command on an interactive shell. I expect that
> signal to remain ignored in the script started from the same shell.
> However, I find disposition of that signal reset to default, even though
> trap command in the script shows that signal is ignored. 
> 
> I am not sure if this is the right behavior. Please help.
> 
> 
> Step 1 - Ignore the signal by typing the following command on an
> interactive shell
> ----------
> $ trap '' SIGXFSZ
> 
> Step 2 - Given below is a script that starts a sleep in the background and
> then sends the signal to that sleep to test if the signal terminates the
> sleep or not.
> ---------
> $ cat test_1.sh 
> trap
> sleep 30&
> sleep 1
> pid=$! 
> kill -s SIGXFSZ $pid
> 
> sleep 1
> kill -0 $pid && echo "sleep survived the signal" && exit
> echo "sleep was terminated by the signal"
> $ 
> 
> Step 3 - Even though the disposition of the signal was set to ignore in the
> Step 1 (and first line of the output of script confirms that), yet, the
> sleep is terminated by the signal. Is it right?

There is a bug here, but it's the fact that the script reports that SIGXFSZ
is ignored.  It's actually not -- the shell sets its disposition back to
whatever it inherited from its parent before executing ./test_1.sh.

There is code in bash to reset signal dispositions but not reset trap
strings when creating some children.  You can read why and see the
discussion at http://austingroupbugs.net/view.php?id=53.  The question is
whether or not the case here, where a subshell is created to execute a
file with the execute bit set but for which execve(2) fails, counts as a
subshell for the purposes of that description.  Clearly it's not both a
subshell for which traps that are not ignored are set to the default and
a subshell for which the trap strings are not freed.

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]