Re: Not quite out of the pipestatus woods yet ...

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 26, 12:45am, Bart Schaefer wrote:
}
} I think it has something to do with the oldjobtab / jobtab switching, but
} have not yet confirmed.

Yes, this definitely it.

[[ DO NOT APPLY THIS DIFF AS A PATCH.  Included for explanation only. ]]

diff --git a/Src/jobs.c b/Src/jobs.c
index c218743..d5e316f 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -945,6 +945,13 @@ printjob(Job jn, int lng, int synch)
 	job = jn - oldjobtab;
     else
 	job = jn - jobtab;
+    /*
+    DPUTS3(job < 0 || job > maxjob,
+	   "bogus job number, jn = %L, jobtab = %L, oldjobtab = %L",
+	   (long)jn, (long)jobtab, (long)oldjobtab);
+    */
+    if (job < 0 || job > maxjob)
+	job = jn - jobtab;
 
     if (jn->stat & STAT_NOPRINT) {
 	skip_print = 1;

With this code change, the stress test never prints the wrong $pipestatus,
regardless of the order of signals arriving.

HOWEVER, with the "setopt MONITOR" added before the stress test, I have
had the shell go into a fast busy in acquire_pgrp() -- the while loop
condition never becomes false but the shell never gets SIGT* either.

I think that's a separate problem, but:  PWS, do you remember enough
about why there is an assumption that oldjobtab never needs to be set
back to NULL once it has been created?  Or is this just a case of not
realizing that printjob() has multiple responsibilities, including the
reaping of old jobs?