On Sun, Nov 15, 2015 at 10:34 AM, Chet Ramey <chet.ra...@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.ra...@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.
