From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23681 invoked from network); 5 Jul 1999 11:07:03 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Jul 1999 11:07:03 -0000 Received: (qmail 5837 invoked by alias); 5 Jul 1999 11:06:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6974 Received: (qmail 5829 invoked from network); 5 Jul 1999 11:06:39 -0000 Date: Mon, 5 Jul 1999 13:06:36 +0200 (MET DST) Message-Id: <199907051106.NAA07331@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Mon, 05 Jul 1999 11:48:23 +0200 Subject: Re: Job control bug with pws-25 Peter Stephenson wrote: > Sven Wischnowsky wrote: > > You didn't miss a patch -- I forgot to play with `bg'. Whew, this was > > a bit more complicated. So much so, that I finally put some of the > > things distributed in jobs.c into functions (super_job() and > > handle_sub()). > > Much improved, thanks. There's still a small bug: > > % fn() { sleep2; print foo; } > % fn > ^Z > % bg > % foo > > The function exited, but no message was printed; notify is set. Running > `jobs' or exiting the shell prints the message. Runing fn directly in the > background behaves as expected. (I think we had something like this once > before, but I don't think it was there when the current saga started.) I think the patch below is the right fix. It says roughly that we are done setting up the super-job once we have turned it into one. There is still a small problem: sometimes I get an empty line before a job-status message even when I shouldn't (because it isn't needed). I haven't found out why the code sometimes thinks it should print that when it shouldn't (but I consider this problem as being not too important). > It seems to me it might be a good idea to collect some of the things which > can potentially go wrong with job control (as well as some which shouldn't > :-)) and put them in a file, say, Misc/job-control-tests. It doesn't need > to run the tests itself, that's far too hard when the bugs are largely > interactive, just give a collection of code with comments saying what you > should do to see if it's working. If I get a moment I'll have a look back > in the archive for some. Yes, and I'll probably have to put some more comments everywhere. Unfortunately I'll be very busy this week again. Bye Sven diff -u os/exec.c Src/exec.c --- os/exec.c Mon Jul 5 12:00:24 1999 +++ Src/exec.c Mon Jul 5 12:58:50 1999 @@ -916,7 +916,7 @@ } jn->stat &= ~(STAT_DONE | STAT_NOPRINT); - jn->stat |= STAT_STOPPED | STAT_CHANGED; + jn->stat |= STAT_STOPPED | STAT_CHANGED | STAT_LOCKED; printjob(jn, !!isset(LONGLISTJOBS), 1); } else if (newjob != list_pipe_job) -- Sven Wischnowsky wischnow@informatik.hu-berlin.de