Re: Clarification needed on signal spec EXIT

2012-10-20 Thread Francis Moreau
Chester,

You could you clarify/help, please ?

On Wed, Oct 17, 2012 at 11:13 AM, Francis Moreau  wrote:
> On Tue, Oct 16, 2012 at 10:00 PM, Bob Proulx  wrote:
>> Francis Moreau wrote:
>>> --
>>> main_cleanup () { echo main cleanup; }
>>> submain_cleanup () { echo sub cleanup; }
>>>
>>> trap main_cleanup EXIT
>>>
>>> task_in_background () {
>>> echo "subshell $BASHPID"
>>>
>>> while :; do
>>> # echo "FOO"
>>> sleep 1
>>> done
>>> echo "subshell exiting..."
>>> }
>>>
>>> {
>>> trap submain_cleanup EXIT
>>> trap
>>> task_in_background
>>> } &
>>>
>>> echo exiting...
>>> --
>>>
>>> Sending TERM signal to the subshell doesn't make "submain_cleanup()"
>>> to be called.
>>
>> And it does in ksh93.  Hmm...  And it does if I comment out the line
>> "trap main_cleanup EXIT".  It seems to only set the trap if no trap
>> handler was previously set.
>
> Yes that's right.
>
> Even weirder: if the subshell exits by calling "exit 1", then the trap
> handler is not called at all regardless of whether or not the "trap
> main_cleanup EXIT" is commented you.
>
> To make that case work, you need to use the "( ... ) &" construct
> instead of "{ ... } &" one.
>
> This is why I was asking for clarification :)
> --
> Francis



-- 
Francis



Re: Clarification needed on signal spec EXIT

2012-10-20 Thread Chet Ramey
On 10/16/12 4:00 PM, Bob Proulx wrote:
> Francis Moreau wrote:
>> --
>> main_cleanup () { echo main cleanup; }
>> submain_cleanup () { echo sub cleanup; }
>>
>> trap main_cleanup EXIT
>>
>> task_in_background () {
>> echo "subshell $BASHPID"
>>
>> while :; do
>> # echo "FOO"
>> sleep 1
>> done
>> echo "subshell exiting..."
>> }
>>
>> {
>> trap submain_cleanup EXIT
>> trap
>> task_in_background
>> } &
>>
>> echo exiting...
>> --
>>
>> Sending TERM signal to the subshell doesn't make "submain_cleanup()"
>> to be called.
> 
> And it does in ksh93.  Hmm...  And it does if I comment out the line
> "trap main_cleanup EXIT".  It seems to only set the trap if no trap
> handler was previously set.

Yes, this is a bug in bash-4.2.  The subshell doesn't properly reinitialize
the traps if a trap has already been set in the parent.  This was fixed in
late July and will be in the next version of bash.

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