Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)
- X-seq: zsh-workers 10016
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)
- Date: Thu, 9 Mar 2000 13:01:32 +0100 (MET)
- In-reply-to: "Bart Schaefer"'s message of Wed, 8 Mar 2000 07:30:38 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> On Mar 3, 2:55am, Geoff Wing wrote:
> } Subject: Re: Preliminary release of 3.0.8 - please test
> }
> } Bart Schaefer <schaefer@xxxxxxxxxxxxxxxxxxxxxxx> 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().
The one in 1031 isn't interesting here, it only makes the sub-shells
created for stopped lists not report their jobs (list_pipe_child is
non-zero only in those sub-shells). Leaves us with the one in 993.
This is used to make sure that jobs started for commands which are
not the first one in a pipeline and jobs started from some kind of
pipeline nesting (e.g. in a loop in a pipeline) are not shown.
Given that, your suggestion:
> 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.
seems sensible. But... how can such a job survive when the super-job
of the (main) pipeline is dead? I wished I could find a way to
reproduce it.
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author