Re: shell jobs -p

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

    Date:        Thu, 13 Sep 2018 14:00:10 +0200
    From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <20180913120009.GE5254%trav.math.uni-bonn.de@localhost>

  | is the job then supposed to show up in "jobs -p" output?
  | In bash, at least for a), the job does show up until you call jobs without -p.
  | In ash and dash, it doesn't show up.

You're using an old version, not NetBSD current (or 8) right?

The way the jobs command affected the jobs table changed in 8
and now the only way for a script to make a job vanish from the
jobs table (and so, from being seen in the output of jobs -p) is
to "wait" for it.   A script can run the jobs command (regardless of
args) as many times as it likes and it will change nothing.

In interactive shells, as running "wait" is not normally something that
interactive users do, once the user has been told that a job is
complete (either via async notification, or from the jobs command)
it is removed, never to be seen again.

The dash behaviour (clearing the jobs table in a subshell) is technically
correct (but as you say, makes life difficult) - the correct way to handle
things like this is to not make a sub-shell to run "simple" command
substitutions which do not affect the current shell environment.   Our
sh used to have a hack to make jobs work OK in a sub-shell which
starts no new jobs (once it starts one, all the parent shell job info is
removed) - but we don't have similar for "trap" which has a similar
problem.   "Used to" in that I see that I broke this sometime, I will fix it...
(It works now if you give specific jobs, as in $( jobs -p %1) but not
with no job identifying args, to just "show all")

Your parallel.jobs.sh doesn't work, as it never does a "wait".

"jobs >/dev/null" might work in bash, but it is not the correct
method.    When I updated the update_queue() function in it
to be more like the one in the parallel.list.sh script, then the
output I see (from a sh with the yet uncommitted fix for the jobs
command) (but I don't know if this is how it is supposed to be run...)

jinx$ ./sh /tmp/parallel.jobs.sh 4 1 2 3 4 5 6 7 8 9
can queue more
queueing 1
func: 1
queued 1: 3483
can queue more
queueing 2
func: 2
queued 2: 2901
can queue more
queueing 3
func: 3
queued 3: 2905
can queue more
queueing 4
func: 4
queued 4: 3414
queue full: 3483 2901 2905 3414
updating queue (size 4)
updated queue: size 4
queue full: 3483 2901 2905 3414
updating queue (size 4)
updated queue: size 4
queue full: 3483 2901 2905 3414
updating queue (size 4)
updated queue: size 4
queue full: 3483 2901 2905 3414
updating queue (size 4)
updated queue: size 4
queue full: 3483 2901 2905 3414
func 2: done
func 1: done
func 3: done
func 4: done
updating queue (size 4)
waiting for 3483
finished: 3483
waiting for 2901
finished: 2901
waiting for 2905
finished: 2905
waiting for 3414
finished: 3414
updated queue: size 0
can queue more
queueing 5
queued 5: 3044
func: 5
can queue more
queueing 6
queued 6: 2803
func: 6
can queue more
queueing 7
queued 7: 5956
func: 7
can queue more
queueing 8
queued 8: 4210
func: 8
queue full: 3044 2803 5956 4210
updating queue (size 4)
updated queue: size 4

(etc).