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);
> }
>
> It seems to me that the new code prevents the subshell from having a
> different terminal control from its parent shell. In other words, no
> isolation happens.
No, that's pretty much the opposite of what it's doing. This is code that
runs when a child process exits and decides whether to set the terminal's
process group back to the shell's process group right then or wait until
later. There are cases where you don't want to do that, such as when a
shell started to run a shell function in a pipeline is waiting for an
external command to complete -- in that case, for example, you want to
defer the decision to change the terminal's process group until the entire
pipeline completes.
(Processes started to run command and process substitution run in the same
process group as the shell and don't give the terminal away. If you turn
on job control in a shell running in a process substitution, though, that
complicates things.)
I'll try to take a look at this on Linux, but I don't happen to have any
Linux systems handy at this moment. The playshell application is way too
big to get a handle on what it might be doing to the terminal or process
groups without instrumenting bash to print a little debugging output and
running playshell. It will take time to set up an environment with some
actual sound files that can reproduce the problem.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
