> 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?
