Re: sleep & Co on Linux

[Sven Mascheck]

Paul Jarc <prj@po.cwru.edu> wrote:

> But Dan's example *was* related to disown

Actually only partly :) It's two problems:
 - does a job release it's "current job" status while being stopped?
 - does the "next recent" job become the current one, if the current
   one gets "disowned" (reomved from the job table)?

(  > not sleep's premature termination.
   That's right, thanks for getting me out of the SIGCONT trap.  )

> The second sleep was started in the background, thus it did not become
> the current job.

But this is what went wrong first.  The _stopped_ job didn't release
it's "current job" status.  The second "sleep &" actually should(?)
have become the current one at once.

The manpage is not 100% clear,
(but ksh88/ksh93 in contrast doesn't care if the "current job"
 is stopped while you launch a new one).

bash(1), JOB CONTROL
     shell's notion of the current job, which  is  the  last  job
     stopped  while  it  was  in the foreground or started in the
     background.

One might argue for both jobs with this sentence.

Anyway, the second becomes the current job, if you "bg" the first
("so that this sort of reacts again?"), on any other OS (but Linux).
It doesn't matter when exactly you do "bg" the first sleep
(before or after launching the second one).


> Then since the current job was just disowned, fg had no current
> job to operte on.

But the second question is if the next recent job should _become_
the new "current job"--the same way as it happens e.g. if you just
kill the current one.  The paragraph for disown in bash(1)
doesn't help me here, either.

Sven