Re: bin/48138

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/48138; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: Steffen Nurpmeso <steffen%sdaoden.eu@localhost>
Subject: Re: bin/48138
Date: Sun, 06 May 2018 00:03:16 +0700

 Thanks for the confirmation - I will close this PR, as I think the
 actual bug in it is fixed.
 
 I suspect (though haven't checked - yet) that the difference
 between the 145 status you saw, and the 127 I see is because
 the sh "wait" command has been rewritten (again) in -current
 (when the -n and -p options were added).
 
 I need to think on what should happen with wait and stopped
 processes -- posix simply says it should wait for all known
 jobs to complete (or all lgiven as args to wait, if any are)
 Nothing about finding stopped processes, or not waiting for
 them to finish.
 
 Assuming wait des not simply wait for the stopped process to
 finish, 127 would be the correct status (I think) when a job/procid
 is given on the command line, as that indicates "not found" and
 here the process was not found exited - the 145 would indicate
 to a script that the process exited with a STGSTOP signal (which
 would be a remarkable feat for it to achieve).
 
 Certainly I don't believe that the wait command should (ever)
 produce jobs style output, and I am not sure bash's warning is
 a good idea either.
 
 But perhaps some other status would be better here, to indicate
 that the process exists, but isn't running, and hasn't exited.
 Or perhaps wait should just ... wait (but as you showed in the
 PR, other shells do not).
 
 I think handling this can be deferred for a while though.
 
 Incidentally, can you tell me which ksh is /bin/ksh on MacOS
 
 	/bin/ksh -c 'echo ${KSH_VERSION}'
 
 kre