Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail
From: konsolebox <konsolebox@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Script shell suspends after executing second child process
Date: Sun, 15 Nov 2015 14:25:03 +0800
Lines: 44
Approved: bug-bash@gnu.org
Message-ID: <mailman.2355.1447656382.7904.bug-bash@gnu.org>
References: <CAJnmqwaW1OfDEwVe9BybW-LP-=-Jr=N83S-xboZYDb5yvQ+cbw@mail.gmail.com> <5644F35F.2050507@case.edu> <CAJnmqwZy0JW_f5NXjQpqT7p=DYjZ=ud4JM3UR+_GqnKPtKk0Dw@mail.gmail.com> <5647BD8A.8060305@case.edu> <5647EF3B.20002@case.edu>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Cc: bug-bash <bug-bash@gnu.org>
To: Chester Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <5647EF3B.20002@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:11883

On Sun, Nov 15, 2015 at 10:34 AM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 11/14/15 6:02 PM, Chet Ramey wrote:
>> On 11/14/15 12:39 PM, konsolebox wrote:
>>> On Fri, Nov 13, 2015 at 4:15 AM, Chet Ramey <chet.ramey@case.edu> wrote:
>>>> On 11/12/15 5:27 AM, konsolebox wrote:
>>>>> My interactive (using `read`) Bash-script application still suspends
>>>>> itself after
>>>>> executing second instance of a player.  I've only seen this happen in
>>>>> the newest development version of Bash.
>>>>
>>>> According to the change log, the last time I made a change that might
>>>> be relevant to this problem was April 23.  You might try getting the
>>>> version immediately preceding that one and seeing whether or not that
>>>> version has the problem.
>>>>
>>>
>>> This seems to be the modification that causes the problem.  It's in
>>> "commit bash-20150424 snapshot".
>>>
>>> --- a/jobs.c
>>> +++ b/jobs.c
>>> @@ -2658,8 +2658,8 @@ itrace("wait_for: blocking wait for %d returns
>>> %d child = %p", (int)pid, r, chil
>>>  if (job == NO_JOB)
>>>    itrace("wait_for: job == NO_JOB, giving the terminal to shell_pgrp
>>> (%ld)", (long)shell_pgrp);
>>>  #endif
>>> -      /* Don't modify terminal pgrp if we are running in the background */
>>> -      if (running_in_background == 0)
>>> +      /* Don't modify terminal pgrp if we are running in background
>>> or a subshell */
>>> +      if (running_in_background == 0 && subshell_environment == 0)
>>>         give_terminal_to (shell_pgrp, 0);
>>>      }
>>>
>
> Here, try this patch.  It sort of splits the difference along the lines of
> your suggestion, and it behaves correctly for the case that inspired the
> change originally.
>

This seems to have fixed it both in bash-20151106 and bash-20150424.
The parent shell no longer suspends.