jobs

jobs

[Jan Stary]

Hello,

trying to keep my shell scripts portable,
I am also testing on systems which use dash;
for instance, /bin/sh is dash in Ubuntu.
That's where my scripts fail because of
how the "jobs" builtin behaves.

First of all, "jobs" is not even mentioned in
http://git.kernel.org/cgit/utils/dash/dash.git/tree/src/dash.1

Some basic functionality seems to be broken.
Start three background jobs:

  $  md5sum < /dev/random &
  $  md5sum < /dev/random &
  $  md5sum < /dev/random &

What jobs am I running?

  $ jobs
  [3] + Running                    md5sum 0</dev/random
  [2] - Running                    md5sum 0</dev/random
  [1]   Running                    md5sum 0</dev/random

Good. How many is that?

  $ jobs | wc -l
  0

Zero. Hm.

  $ jobs
  [3] + Running                    md5sum 0</dev/random
  [2] - Running                    md5sum 0</dev/random
  [1]   Running                    md5sum 0</dev/random

No, wait, it's three. Let's kill them:

  $ kill `jobs -p`
  dash: 10: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... 
  kill -l [exitstatus]

What's the pid list again?

  $ jobs -p
  30783
  30782
  30780


Is this intended? The behaviour descibed above can't be right.
Does the pipe or the `...` run in it's own shell (which indeed has no jobs)?
In that case, I can circumvent this with a temporary file, as in

  $ jobs > /tmp/jobs
  $ wc -l < /tmp/jobs

but doing that instead of a pipe seems backward at best.

	Jan

Re: jobs

[Harald van Dijk]

Hello,

On 21/12/2016 13:34, Jan Stary wrote:
 > Hello,
 >
 > trying to keep my shell scripts portable,
 > I am also testing on systems which use dash;
 > for instance, /bin/sh is dash in Ubuntu.
 > That's where my scripts fail because of
 > how the "jobs" builtin behaves.
 >
 > First of all, "jobs" is not even mentioned in
 > http://git.kernel.org/cgit/utils/dash/dash.git/tree/src/dash.1

Indeed, it's a built-in command, so it would make sense to document it 
along with the other built-in commands.

 > Some basic functionality seems to be broken.
 > Start three background jobs:
 >
 >   $  md5sum < /dev/random &
 >   $  md5sum < /dev/random &
 >   $  md5sum < /dev/random &
 >
 > What jobs am I running?
 >
 >   $ jobs
 >   [3] + Running                    md5sum 0</dev/random
 >   [2] - Running                    md5sum 0</dev/random
 >   [1]   Running                    md5sum 0</dev/random
 >
 > Good. How many is that?
 >
 >   $ jobs | wc -l
 >   0

This is discussed in <https://www.spinics.net/lists/dash/msg01161.html>. 
It's certainly not desired behaviour and equally certainly not what 
POSIX intends, given that POSIX gives examples involving $(jobs -p). 
Arguably though, it may be what POSIX requires, and even if not, it's 
not clear exactly what POSIX does require. I offered to try to come up 
with a patch to make it behave more sensibly if there was a reasonable 
chance it would be accepted, but the dash maintainer (Herbert Xu) hasn't 
commented on this yet. Hoping to hear his ideas on what should work and 
what shouldn't.

A slightly less bad workaround than redirecting to a temporary file 
might be to save each PID in a variable immediately after creating the 
background process, using $!.

Cheers,
Harald van Dijk

jobs

[Sage Weil]

Hi all,

Just a quick note that we have some job openings for those interested in 
getting paid to work on Ceph.  The main one we're trying to fill now is a 
QA person.  We are also always looking for qualified developers, both for 
the server side (C/C++) and kernel side.

http://ceph.newdream.net/jobs

sage