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


``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/

Attachment: job-control-init.patch
Description: Source code patch

reply via email to

[Prev in Thread] Current Thread [Next in Thread]