Re: shell jobs -p

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> You're using an old version, not NetBSD current (or 8) right?
6.1, mostly (for the ash part), yes.

> 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.
Surely you've digested what SUS says about this. I didn't try too hard, 
but I didn't grasp it. Could you explain what SUS allows?

> 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.
OK, I understand.

> The dash behaviour (clearing the jobs table in a subshell) is technically
> correct (but as you say, makes life difficult)
I'm not sure whether we are talking about the same thing.

What I mean is that if you have background jobs running, jobs -p will 
surely list them. However, if you want to use jobs -p output in a script,
the only way is to run it inside $(...). That's a (potential) subshell 
environment, and in dash, the output of $(jobs -p) is always empty.
While I suppose the words of SUS allow that, SUS also gives $(jobs -p) 
as an example, which, in dash, could better be written "". This cannot 
be intended.

> 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.
I don't get that. Either we're talking past each other or I simply don't 
understand what you mean.
Can you give a way where jobs -p and [insert your code here] echo "$j" 
give the same output in dash?

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

> "jobs >/dev/null" might work in bash, but it is not the correct
> method.
Yes, sure.

> 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
Yes, that's the intended way (which I guess is obvious from the source).

Would you say parallel.list.sh is portable?