am I in background?

[William LeFebvre]

>Ron Natalie:
> On shells with job control, all it does is switch the terminal process
> group to something different than the running process.  The
> standard input is not touched.  However if the standard input
> is still the terminal, the user will read EOF whenever he tries
> to read it, unless he is catching SIGTTIN.

What?  Not with the c-shell.  If the login process (the shell) still
has the control terminal open, then the process doing the read always
gets a SIGTTIN (actually, the whole process group get the TTIN).
Otherwise, the read returns with an EBADF (of course, stdio translates
an EBADF into an EOF).  The default action for TTIN is to stop the
process.  If TTIN is being held or ignored, then the read returns an
EIO.  When a process gets stopped for any reason (in this case, from a
TTIN), the parent process (usually the c-shell) gets a SIGCHLD,
indicating that a child's status has changed.

The result is that when you put a process in the background that then
tries to read from your terminal, the c-shell will say "Stopped (tty
input) ...".  This happens without any unusual action on the part of
the child -- it is the default.  This turns out to be very handy,
especially with an interactive program that has a long startup time
(such as TeX).  One can start the program in the background and go off
and do something else while it starts up (like make small changes to an
input file).  When it is ready, it will get stopped.  Then the user can
simply "fg" it and start typing.  Unfortunately, emacs doesn't benefit
from this since it does an ioctl on the terminal (which has similar
consequences) before it does all of its startup stuff (like reading the
profile).

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil at Rice.arpa>
                        or, for the daring: <phil at Rice.edu>