Prev: Convert to integer
Next: Redirecting stdin to a file requiring parameters
From: Chad on 24 Jun 2008 13:04
Can some explain to me why non-interactive shells don't support job
control? I don't get the reasoning.

Chad
From: Chad on 24 Jun 2008 13:05
On Jun 24, 10:04 am, Chad <cdal...(a)gmail.com> wrote:
> Can some explain to me why non-interactive shells don't support job
> control? I don't get the reasoning.
>
> Chad

I guess I'm not also drawing a clear distinction between job control
and a background job.
From: Stephane CHAZELAS on 24 Jun 2008 14:41
2008-06-24, 10:04(-07), Chad:
> Can some explain to me why non-interactive shells don't support job
> control? I don't get the reasoning.
[...]

Job control has to do with terminal handling. Starting a job in
foreground means doing an ioctl to the terminal to tell it that
only that process group is allowed to read from the terminal and
is the only one to get the SIGINT, SIGQUIT, SIGTSTP upon
<Ctrl-C>, <Ctrl-\>, <Ctrl-Z>...

On a given terminal, you can have only one process doing job
control (that is, deciding which process group is the foreground
process group of the terminal), as there is only one foreground
process group.

Imagine what would happen if several shells were to make that
choice without cooperation between each other.

--
St�phane
From: Barry Margolin on 24 Jun 2008 15:26
In article
<bc620480-5bc5-4138-a255-5c6a2eeff94f(a)f1g2000prb.googlegroups.com>,
Chad <cdalten(a)gmail.com> wrote:

> On Jun 24, 10:04�am, Chad <cdal...(a)gmail.com> wrote:
> > Can some explain to me why non-interactive shells don't support job
> > control? I don't get the reasoning.
> >
> > Chad
>
> I guess I'm not also drawing a clear distinction between job control
> and a background job.

A background job is a job that's running concurrently with the shell or
some other foreground job. When you put a job in the backgorund the
shell prompt comes back immediately, while the program continues to run,
and you can start other programs. When a job is in the foreground the
shell waits for it to finish before giving you another prompt.

Also, the foreground job is usually the only one that's allowed to take
input from the user via the terminal; if a background job tries to read
from the terminal it's stopped.

Job control is the ability to move jobs between foreground, stopped, and
background on the fly. Before job control, you had to make the decision
at the time you started a job: you either run it in the background by
appending '&' to the command line, or run it in the foreground by
default. Once it was in the background you couldn't change it to
foreground, or vice versa. With job control you can stop a foreground
job with Control-z, then restart it either in the foreground or
background with fg or bg.

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Chad on 24 Jun 2008 15:54
On Jun 24, 12:26 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote:
> In article
> <bc620480-5bc5-4138-a255-5c6a2eeff...(a)f1g2000prb.googlegroups.com>,
>
>  Chad <cdal...(a)gmail.com> wrote:
> > On Jun 24, 10:04 am, Chad <cdal...(a)gmail.com> wrote:
> > > Can some explain to me why non-interactive shells don't support job
> > > control? I don't get the reasoning.
>
> > > Chad
>
> > I guess I'm not also drawing a clear distinction between job control
> > and a background job.
>
> A background job is a job that's running concurrently with the shell or
> some other foreground job.  When you put a job in the backgorund the
> shell prompt comes back immediately, while the program continues to run,
> and you can start other programs.  When a job is in the foreground the
> shell waits for it to finish before giving you another prompt.
>
> Also, the foreground job is usually the only one that's allowed to take
> input from the user via the terminal; if a background job tries to read
> from the terminal it's stopped.
>
> Job control is the ability to move jobs between foreground, stopped, and
> background on the fly.  Before job control, you had to make the decision
> at the time you started a job: you either run it in the background by
> appending '&' to the command line, or run it in the foreground by
> default.  Once it was in the background you couldn't change it to
> foreground, or vice versa.  With job control you can stop a foreground
> job with Control-z, then restart it either in the foreground or
> background with fg or bg.
>
> --

Then how come you can't have job control in a non-interactive shell
(via a script)
?
Chad
 |  Next  |  Last
Pages: 1 2 3
Prev: Convert to integer
Next: Redirecting stdin to a file requiring parameters