Re: Odd job-reporting buglet (Re: Change in suspend behavior)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

We were both on the wrong track.  The code once handled that correctly
but then came the change in 6819 that made

  foo | while true; do bar; done

suspendable (with a quickly finishing bar).  The change made execpline()
test the state of `foo', by adding:

		     (list_pipe_job && pline_level &&
		      (jobtab[list_pipe_job].stat & STAT_STOPPED)))) {

But in cases like the one we're discussing now, the list_pipe_job was
set when starting the loop and ended up pointing to a job in the loop.

So the patch below tries to fix this at a completely different place --
setting up list_pipe_job only if we are building a job for a real pipe
into a loop or something (not for a loop not inside a pipe).

Seems to work for me, without breaking what I said above, so I'm going
to commit it.

Bye
  Sven

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.26
diff -u -r1.26 exec.c
--- Src/exec.c	2001/03/30 16:51:54	1.26
+++ Src/exec.c	2001/05/14 08:49:23
@@ -973,10 +973,10 @@
      * stopped, the top-level execpline() didn't get the pid for the
      * sub-shell because it was overwritten. */
     if (!pline_level++) {
-	list_pipe_job = newjob;
         list_pipe_pid = 0;
 	nowait = 0;
 	simple_pline = (WC_PIPE_TYPE(code) == WC_PIPE_END);
+	list_pipe_job = (simple_pline ? 0 : newjob);
     }
     lastwj = lpforked = 0;
     execpline2(state, code, how, opipe[0], ipipe[1], last1);

-- 
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx