Functions that start Jobs

Functions that start Jobs

[Gregory Margo]

I have a Function that starts a process in the background.
The Job created is "%2" instead of "%1".
Why is this?
How can I make it be the first Job?

Here's the function:

function makeb() {
        nice make $* 2>&1 > Make.out &
}

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
Home: gmargo@yahoo.com
Work: gmargo@spam-spam-spam-bacon-and-spam.com

Re: Functions that start Jobs

[Bart Schaefer]

On Jun 28,  3:33pm, Gregory Margo wrote:
> Subject: Functions that start Jobs
> I have a Function that starts a process in the background.
> The Job created is "%2" instead of "%1".
> Why is this?

Because the function itself is job %1.  It doesn't show up in the output
of "jobs" because it's being executed within the current shell process,
but it still has a job table entry.

> How can I make it be the first Job?

You can't.  Even if the function didn't use up one job slot, what if
there were some other background job already running?

Why is it important that it be the first job?

Re: Functions that start Jobs

[Gregory Margo]

On Thu, Jun 28, 2001 at 05:07:38PM -0700, Bart Schaefer wrote:
> On Jun 28,  3:33pm, Gregory Margo wrote:
> > Subject: Functions that start Jobs
> > I have a Function that starts a process in the background.
> > The Job created is "%2" instead of "%1".
> > Why is this?
> 
> Because the function itself is job %1.  It doesn't show up in the output
> of "jobs" because it's being executed within the current shell process,
> but it still has a job table entry.
> 
> > How can I make it be the first Job?
> 
> You can't.  Even if the function didn't use up one job slot, what if
> there were some other background job already running?
> 
> Why is it important that it be the first job?

Consistancy.  I've used this alias and others, with job control under
several shells, for many years.

If I type it on the command line, it's job %1.
If I make it a zsh alias, without the $*, then it's job %1.
When I used csh/tcsh, my alias created job %1.
When I used bash, my function (same as zsh function) created job %1.

In general, when I put something in the background (nothing else already
there) then I expect it to be job %1.

Why does a function take up a job slot?
And if it does, why doesn't 'exec' work?

thanks,
gm
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
Home: gmargo@yahoo.com
Work: gmargo@spam-spam-spam-bacon-and-spam.com

Re: Functions that start Jobs

[Sven Wischnowsky]

Gregory Margo wrote:

> ...
> 
> Why does a function take up a job slot?
> And if it does, why doesn't 'exec' work?

Because no other shell can do this:

  % f() { sleep 10; echo foo }
  % f
  ^Z
  zsh: 4022 suspended  f
  % fg
  [1]  + continued  f
  [ time passes... ]
  foo

Note that it reported that it had stopped the job `f' and that the `foo'
was printed after the `sleep' finished.

With bash:

  $ f() { sleep 10; echo foo; }
  $ f
  ^Z
  [1]+  Stopped               sleep 10
  foo
  $

Ick!


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Functions that start Jobs

[Bart Schaefer]

On Jun 29,  1:04am, Gregory Margo wrote:
}
} Why does a function take up a job slot?

Because you can suspend it with ^Z, and at that point it does become a
separate job that appears in the "jobs" output.

E.g.

zagzig% foo() { sleep 30 & sleep 10 }
zagzig% foo
[2] 13882
<ctrl-Z>
zsh: suspended  foo
zagzig% jobs
[1]  + suspended  foo
[2]  - running    sleep 30

} And if it does, why doesn't 'exec' work?

If you mean what I think you mean, then the reason is that 'exec' deals
with processes -- it makes a new process replace the old process.  But
job table entries are not processes; they're just zsh's internal method
of doing record-keeping for commands in progress.

Loops take up a job table slot too:

zagzig% jobs
zagzig% repeat 2 do sleep 5 & done
[2] 13890
[3] 13891

Here "repeat ..." is job 1, so the backgrounded sleeps become 2 and 3.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Functions that start Jobs

[Vincent Lefevre]

On 29 Jun, Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote:

> Because no other shell can do this:

>   % f() { sleep 10; echo foo }
>   % f
>   ^Z
>   zsh: 4022 suspended  f
>   % fg
>   [1]  + continued  f
>   [ time passes... ]
>   foo

I have 2 questions:

1) Is the function executed in the current shell? I don't understand
what happens exactly. What happens if Ctrl-Z is typed while a builtin
is being executed?

2) I tried this example (with 100 instead of 10, to have more time),
and after I typed fg, the sleep ends immediately (i.e., no time
passes). I have the same behaviour on two machines under Linux
(Linux/x86 and Linux/ppc). Is this normal?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Functions that start Jobs

[Sven Wischnowsky]

Vincent Lefevre wrote:

> On 29 Jun, Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote:
> 
> > Because no other shell can do this:
> 
> >   % f() { sleep 10; echo foo }
> >   % f
> >   ^Z
> >   zsh: 4022 suspended  f
> >   % fg
> >   [1]  + continued  f
> >   [ time passes... ]
> >   foo
> 
> I have 2 questions:
> 
> 1) Is the function executed in the current shell? I don't understand
> what happens exactly.

It gets wrapped into a sub-shell, i.e. you have to accept the same
consequences as if you had started it in the background from the
beginning -- it can't influence the main shell anymore (setting
parameters and things like that).

> What happens if Ctrl-Z is typed while a builtin
> is being executed?

(Very good. ;-) That won't work because we need something to find out
that something got suspended.  Some time ago we were discussing if it
was possible to make this work, too.  I don't remember exactly, but
nothing came of it.

> 2) I tried this example (with 100 instead of 10, to have more time),
> and after I typed fg, the sleep ends immediately (i.e., no time
> passes). I have the same behaviour on two machines under Linux
> (Linux/x86 and Linux/ppc). Is this normal?

It depends on how your `sleep' is written.  Some versions just put
themselves to sleep and almost any signal makes them continue (i.e.:
finish).  On other Unices (for example, this Tru64 here), `sleep' takes
its job a bit more serious and doesn't exit immediately after it gets a
SIGCONT.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Functions that start Jobs

[Bart Schaefer]

On Jun 29, 11:16am, Sven Wischnowsky wrote:
} Subject: Re: Functions that start Jobs
}
} Vincent Lefevre wrote:
} 
} > What happens if Ctrl-Z is typed while a builtin
} > is being executed?
} 
} (Very good. ;-) That won't work because we need something to find out
} that something got suspended.  Some time ago we were discussing if it
} was possible to make this work, too.  I don't remember exactly, but
} nothing came of it.

It'd be pretty messy.  We'd either have to fork() in a signal handler
(which I'm sure is not a good idea), or else set a flag for TSTP the way
zsh presently does for INT -- and then at every point where we check the
INT'd flag, also check the TSTP'd flag and fork(), with the child then
STOPping itself and the parent breaking out as if INT'd.

Or we could use pthreads and put every command that's executed in the
current shell into its own thread.  But without a massive rewrite, we'd
have to make sure that no more than one thread at a time (including the
"parent" one) was ever executing -- so either it would not be possible
to put a stopped builtin in the background, or we'd still have to fork()
and continue only one thread in each process, and I'm really not sure if
that works any better than forking in a signal handler.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net