bug in force_interactive handling

[Stas Sergeev]

Hi.

It seems the -i switch of the bash doesn't work as expected
these days (I tried with bash-4.1).
I've found 2 places of the breakage.

1. initialize_job_control () has the following code:
---
  if (interactive == 0)
    {
      job_control = 0;
      original_pgrp = NO_PID;
      shell_tty = fileno (stderr);
    }
  else
    {
      shell_tty = -1;
   
      /* If forced_interactive is set, we skip the normal check that stderr
 is attached to a tty, so we need to check here.  If it's not, we
 need to see whether we have a controlling tty by opening /dev/tty,
 since trying to use job control tty pgrp manipulations on a non-tty
 is going to fail. */
      if (forced_interactive && isatty (fileno (stderr)) == 0)
---

But, -i sets "interactive_shell" variable, not "interactive", so the
aforementioned comment and code makes no sense, though it
might have been working in the past.

2. waitchld() has the code like this:
---
      /* We don't want to be notified about jobs stopping if job control
         is not active.  XXX - was interactive_shell instead of
job_control */
      waitpid_flags = (job_control && subshell_environment == 0)
                        ? (WUNTRACED|wcontinued)
                        : 0;
---

In particular, the XXX part makes sense: it used to work when it
was checking "interactive_shell" (for the reason mentioned above),
but now it doesn't because "job_control" gets reset together with
"interactive".

The result of this all is that if some script is being run with
"bash -i" and that script starts some binary, bash wouldn't honour
the SIGSTOP sent to that binary.

I made a quick patch to fix the problem, it is attached.
Can someone please take a look into that?

(please CC me the replies)

interact.diff
Description: Text document