NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/48138
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
Home |
Main Index |
Thread Index |
Old Index