CS 279 - Week 3 Lecture 2 - 9-6-12

*   more on processes...

*   much of this is from Chapter 2 of the course text!!

*   exit status of a process
    *   3 possible outcomes of calling a process:
        success
        failure
        abnormal termination

    *   the EXIT STATUS of the process is a number
        that indicates which is the case;

        *   a process can terminate normally of its
            own accord, returning an exit status to
            its parent

        *   by UNIX/Linux convention, an exit status of 0
            indicates success

        *   any OTHER exit status value indicates failure;
            the actual value can indicate the nature of the
	    failure;

            *   by convention (not sure how universal!)
                a normal "failure" exit status is less than
                128 to avoid confusion with an exit status
                resulting from abnormal termination
 
            *   for abnormal termination -- say, an interrupt
                or other signal -- the process itself may not
		be able to return an exit status because
		it may have lost control,

		so the KERNEL returns an exit status on
		behalf of that process indicating why it
		terminated,
                in this case, often 128 + the signal
		code number (137 of you kill the process
                with SIGKILL, kill -9, for example)

*   so, one can test the exit status of a process
    and use that to determine what to do next;

A little more on job control...
*   "job control", by definition, is a shell facility,
    intro'd by BSD and standardized by POSIX,
    that enables you to create groups of processes called
    JOBS
    and to control them from your shell session using
    shell commands.

    *   a job, then, can be thought of (I think!) as
        collection of 1 or more processes;

*   Consider: one COULD consider that, when you are
    logged in, your shell is in ONE of TWO states:
    1. at a shell prompt awaiting your command/input
    2. OR it is executing a command that has control of
       the terminal

    *   IF the shell is executing a command, then the processes
        entailed in that execution constitute the FOREGROUND
	job
  
    *   Thus, at a given time, there is either ONE foreground
        job, or NONE;

*   in addition, ANY number of jobs can be running in the
    background or stopped (suspended)
    *   a RUNNING BACKGROUND JOB is a job that is running but it is
        NOT the foreground job

    *   a STOPPED BACKGROUND JOB is in a suspended state;
        it remains dormant until you take action to resume it

    *   If there are ANY stopped background jobs,
        the CURRENT JOB is the one that was stopped MOST
        RECENTLY <-- that's the one marked with + in
	the jobs command output;

        *   OTHERWISE, the CURRENT JOB, if any, is the 
            background job MOST RECENTLY suspended or
            initiated

        *   YES, this does mean that, in terms of the
	    definition of current job, a stopped job
	    does get "priority" over a running background
	    job;

        *   if there are NO background jobs or stopped jobs,
            then the current job is UNDEFINED.

*   note that 1 way to start a background job is to
    end the command with an ampersand (&)

    emacs moo &

    *   when you start it this way, the shell shows
        the job number and the process id associated
	with that job

*   interesting tidbit: when a job terminates or changes
    status in some way, 
    the shell NOTIFIES you of the change JUST before
    it issues the next command prompt;

*   it a running background job attempts to read from
    the terminal, it is stopped (until it becomes the
    foreground job, and then it can read from the
    terminal...)

    *   if a running background job attempts to write to
        the terminal, whether it stops or merrily writes
	to the screen depends on the setting of
	the terminal setting tostop

    *   (terminal output stop, maybe...?)
    *   if tostop is ENABLED, such a running background
        process will be stopped until the job is moved
	to the foreground;
	
	if tostop is disabled, the output from that
	running background process may be intermingled
        with output from the foreground process