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, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.2-patched/shell.c 2011-01-02 16:04:51.000000000 -0500
--- shell.c 2011-12-29 09:18:52.000000000 -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 */
}
