bin/52641: /bin/sh "jobs" command incorrectly does an implicit "wait" on completed jobs

[kre%munnari.OZ.AU@localhost]

>Number:         52641
>Category:       bin
>Synopsis:       /bin/sh "jobs" command incorrectly does an implicit "wait" on completed jobs
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 23 06:05:00 +0000 2017
>Originator:     Robert Elz
>Release:        NetBSD 8.99.1  (essentially all of them)
>Organization:
>Environment:
System: NetBSD andromeda.noi.kre.to 8.99.1 NetBSD 8.99.1 (VBOX64-1.3-20170812) #39: Sat Aug 12 15:25:04 ICT 2017 kre%magnolia.noi.kre.to@localhost:/usr/obj/current/kernels/amd64/VBOX64 amd64
Architecture: x86_64
Machine: amd64
>Description:
	When the "jobs" command is performed, /bin/sh discards the
	status of any job it displays which is completed.

	That's (arguably) acceptable for interactive shells, which is
	where "jobs" is most commonly used (though probably technically
	incorrect - but it mirrors the behaviour of interactive shells only
	ever displaying the status of a completed job once) but is simply
	wrong for scripts.

>How-To-Repeat:
	If you had a shell where PR bin/52640 is fixed already, and this
	PR is not, you'd run the following script ...

#! /bin/sh

for f in 1 2 3 4 5 6
do
	(sleep $f && exit $f) & eval P$f=$!
done

jobs -l

sleep 10

jobs -l

wait $P1 $P3 $P5
echo Status $?

jobs -l

wait $P6 $P4
echo Status $?

jobs -l

wait $P2
echo Status $?

jobs -l

	And observe that the "Status" reports all say 127, and that there
	is no more output from the "jobs" command after the first one
	after the "sleep 10" which shows all of the background jobs as "Done".

	The Status messages should be "5" "4" and "2"

	Whether "jobs" should display the unwaited for jobs, or only those
	not previously displayed as "done" is unclear, and not the same
	in other shells - bash and ksh display completed jobs only once,
	FreeBSD's sh keeps showing them in the jobs command until they're
	waited on.   dash has the same bug that our /bin/sh has.

	Of course, none of you will ever actually observe this, as
	this problem will be fixed in the same commit as the one that
	fixes bin/52640

>Fix:
	Arrange for non-interactive shells to leave the jobs table alone
	when performing a "jobs" command - we will continue to let "jobs"
	in interactive shells act just like "wait" as that's what it is
	commonly used for (a kind of polling wait.)

	Fix coming soon...