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.
> 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() ).
> 2. waitchld() has the code like this:
> ---
> /* We don't want to be notified about jobs stopping if job control
> is not active. XXX - was interactive_shell instead of
> job_control */
> waitpid_flags = (job_control && subshell_environment == 0)
> ? (WUNTRACED|wcontinued)
> : 0;
> ---
>
> In particular, the XXX part makes sense: it used to work when it
> was checking "interactive_shell" (for the reason mentioned above),
> but now it doesn't because "job_control" gets reset together with
> "interactive".
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.
>
> 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'.
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/
