[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug in force_interactive handling
From: |
Chet Ramey |
Subject: |
Re: bug in force_interactive handling |
Date: |
Thu, 29 Dec 2011 11:54:06 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
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 address@hidden http://cnswww.cns.cwru.edu/~chet/
job-control-init.patch
Description: Source code patch