Re: bug in force_interactive handling

[Stas Sergeev]

Hi Chet, thanks for taking a look.

28.12.2011 01:16, Chet Ramey wrote:
> 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.
Lets get this double-checked.

>> 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() ).
-i does not end up setting `interactive' when used from the
script, see shell.c:init_interactive_script(). Sorry for not mentioning
initially that I am talking about the script, but I thought "-i" is
mainly useful for scripts.
So, after init_interactive_script() and "-i" we have
interactive==0, forced_interactive==1, interactive_shell==1.
With the code above, "forced_interactive" gets ignored.
Is this still not a bug?

> 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.
Why this "usually will" does not apply to the scripts?
The comments in the code clearly suggests this was the
case. Namely, they used to check "interactive_shell"
in waitchld() in the past, but now they check "job_control".
Have the bash changed its behaveor recently?

>> 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'.
Thanks: "set -m" together with "-i" kind of works...
The problem now is that bash thinks this job is stopped
forever, even after I send SIGCONT. Then it calls
terminate_stopped_jobs() to the running process... :(
Do you know how to solve this?

The test is simple:
---
#!/bin/bash -i
set -m; cat
echo Finished!
while :; do sleep 2; jobs; done
---
Send SIGSTOP to cat, then SIGCONT.
It is still displayed as "Stopped".