From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3191 invoked from network); 10 Mar 2000 09:35:20 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Mar 2000 09:35:20 -0000 Received: (qmail 10394 invoked by alias); 10 Mar 2000 09:35:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10042 Received: (qmail 10386 invoked from network); 10 Mar 2000 09:35:07 -0000 Date: Fri, 10 Mar 2000 10:33:37 +0100 (MET) Message-Id: <200003100933.KAA03375@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Sven Wischnowsky's message of Thu, 9 Mar 2000 13:01:32 +0100 (MET) Subject: Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test) I wrote: > Bart Schaefer wrote: > > ... > > > > 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. I've played some more yesterday evening/night but still couldn't get it to happen (with dev-19, that is). Geoff, do you remember what you did before you got that message? Did you kill some job/process? What (kind of) commands did you suspend? Pipes with lists in them, commands that do some kind of signal handling? (Yes, I'm guessing wildly...) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de