Re: bug in force_interactive handling

[Chet Ramey]

On 12/26/11 10:12 AM, Stas Sergeev wrote:
> Hi.
> 
> It seems the -i switch of the bash doesn't work as expected
> these days (I tried with bash-4.1).

I'm not sure what `expected' means here; both code fragments are
correct.

> 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.

`-i' sets the `forced_interactive' variable; look at flags.c.  The shell
sets interactive and interactive_shell internally. (And -i does end up
setting `interactive'; look at shell.c:init_interactive() ).

> 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".

Job control isn't controlled by the `-i' option; it's the `-m' option.
Interactive shells and shells with job control are not the same thing;
you can have one without the other.  A shell that would ordinarily
be non-interactive (e.g., started to run a script, or as part of a
pipeline) but is forced interactive using `-i' need not have job control
enabled, though it usually will.

> 
> 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.

What does `honour the SIGSTOP' mean here?  If you want job control,
try putting `set -m' into the script if $- doesn't include `m'.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/