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. I'm not sure about the rationale but, should we at
least not do it in subshells induced by process substitution and
command substitution? Just my quick thoughts. I'll still look more
into it.
