Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Mar 3,  2:55am, Geoff Wing wrote:
} Subject: Re: Preliminary release of 3.0.8 - please test
}
} Bart Schaefer <schaefer@candle.brasslantern.com> typed:
} :On Feb 29, 10:33am, Geoff Wing wrote:
} :} Subject: Re: Preliminary release of 3.0.8 - please test
} :} After some initial usage, got it into a state of:
} :} % %
} :} fg: no such job: 3
} :} % %%
} :} fg: no such job: 3
} :} % fg
} :} fg: no current job
} :} % jobs
} :} %
} :Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
} :can get 3.0.8 into that state theres a problem for 3.1.6 as well.
} 
} I'm thinking that getjob() may need a setcurjob() before it checks curjob.

Since Sven has been incommunicado for a couple of days, I tried to look
into this myself in more detail.  The only two places where getjob() is
called are from bin_kill(), and from bin_fg() *after* the setcurjob()
that you noted.

I can believe that a race condition might cause "no such job: 3" once,
but twice in a row is impossible.  So the only possible answer is that
the one and only job has STAT_NOPRINT set but *not* STAT_SUBJOB, which
in turn happens only at exec.c:768 and 806 (in 3.0.8; in 3.1.6-dev-19,
exec.c:993 and 1031), both in execpline().  See jobs.c:setprevjob(),
which is called from setcurjob().

Now, it may be that the right solution is to have setprevjob() ignore
jobs that have STAT_NOPRINT set, but I wouldn't want that to mask some
more serious job-state problem.  If you have any insights, share 'em.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com