Re: bash sends SIGHUP to disowned children in non-interactive mode

[Chet Ramey]

On 12/28/11 5:57 PM, Philip wrote:

> So without job control bash might (I know, we don't know for sure)
> send the SIGHUP to all processes started in the shell, whether child
> by definition or not?

No, it doesn't.

> Shouldn't the -i flag enable job control by the way?

Yes, and it does.  The problem is that bash inappropriately turns job
control off if -i is supplied with a shell script.  I've attached a
patch that fixes that.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.2-patched/shell.c	2011-01-02 16:04:51.0 -0500
--- shell.c	2011-12-29 09:18:52.0 -0500
***
*** 1620,1624 
no_line_editing = 1;
  #if defined (JOB_CONTROL)
!   set_job_control (0);
  #endif /* JOB_CONTROL */
  }
--- 1620,1626 
no_line_editing = 1;
  #if defined (JOB_CONTROL)
!   /* Even if the shell is not interactive, enable job control if the -i or
!  -m option is supplied at startup. */
!   set_job_control (forced_interactive||jobs_m_flag);
  #endif /* JOB_CONTROL */
  }

Re: bug in force_interactive handling

[Chet Ramey]

On 12/28/11 4:42 AM, Stas Sergeev wrote:

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

You're on the right track.  The fix is to pay attention to the values
of forced_interactive and jobs_m_flag (the variables set by -i and -m,
respectively) when setting job control in init_noninterative().  I've
attached a patch that does the right thing.

When you run bash with -i, interactive and interactive_shell are set
when initialize_job_control is called, so the correct initialization
happens.  It's only later that job control gets turned off inappropriately.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.2-patched/shell.c	2011-01-02 16:04:51.0 -0500
--- shell.c	2011-12-29 09:18:52.0 -0500
***
*** 1620,1624 
no_line_editing = 1;
  #if defined (JOB_CONTROL)
!   set_job_control (0);
  #endif /* JOB_CONTROL */
  }
--- 1620,1626 
no_line_editing = 1;
  #if defined (JOB_CONTROL)
!   /* Even if the shell is not interactive, enable job control if the -i or
!  -m option is supplied at startup. */
!   set_job_control (forced_interactive||jobs_m_flag);
  #endif /* JOB_CONTROL */
  }