JOBS(1CSH)              COMMAND REFERENCE              JOBS(1CSH)



NAME
     jobs - c-shell job control

SYNOPSIS
     jobs [ -l ]

DESCRIPTION
     The jobs command is used to print information about jobs
     being run by the csh(1csh). This document describes the csh
     job control facility.

     Csh associates a job with each pipeline or command.  It
     keeps a table of current jobs, printed by the jobs command,
     and assigns them small integer numbers (an attempt is made
     to keep the job numbers less than 10 by wrapping back to 1
     after job 9).  When a job is started asynchronously with &,
     the shell prints a line which looks like:

          [1] 1234

     indicating that the jobs which was started asynchronously
     was job number 1 and had one (top-level) process, whose
     process id was 1234.

     If you are running a job and wish to do something else you
     may hit <CNTRL Z> which sends a STOP signal to the current
     job.  The shell will then normally indicate that the job has
     been `Stopped', and print another prompt.  You can then
     manipulate the state of this job, putting it in the
     background with the bg command, or run some other commands
     and then eventually bring the job back into the foreground
     with the foreground command fg.  A <CNTRL Z> takes effect
     immediately and is like an interrupt in that pending output
     and unread input are discarded when it is typed.  There is
     another special key, <CNTRL Y>, which does not generate a
     STOP signal until a program attempts to read(2) it.  This
     can usefully be typed ahead when you have prepared some
     commands for a job which you wish to stop after it has read
     them.

     A job being run in the background will stop if it tries to
     read from the terminal.  Background jobs are normally
     allowed to produce output, but this can be disabled by
     giving the command stty tostop.  If you set this tty option,
     then background jobs will stop when they try to produce
     output like they do when they try to read input.

     There are several ways to refer to jobs in the shell.  The
     character % introduces a job name.  If you wish to refer to
     job number 1, you can name it as %1.  Just naming a job
     brings it to the foreground; thus %1 is a synonym for fg %1,
     bringing job 1 back into the foreground.  Similarly saying



Printed 5/12/88                                                 1

JOBS(1CSH)              COMMAND REFERENCE              JOBS(1CSH)



     %1 & resumes job 1 in the background.  Jobs can also be
     named by prefixes of the string typed in to start them, if
     these prefixes are unambiguous; thus %ex would normally
     restart a suspended ex(1) job, if there were only one
     suspended job whose name began with the string ex.  It is
     also possible to say %?string which specifies a job whose
     text contains string, if there is only one such job.

     The shell maintains a notion of the current and previous
     jobs.  In output pertaining to jobs, the current job is
     marked with a + and the previous job with a - (dash).  The
     abbreviation %+ refers to the current job, and %- refers to
     the previous job.  For close analogy with the syntax of the
     history mechanism (described in history(1csh)), %% is also a
     synonym for the current job.

OPTIONS
     -l Print a long listing of all job information.  The process
        id and working directory for the job are printed.

EXAMPLES
     Assume that you ran the command ``ex file'' in the directory
     /usr/fred, suspended the job, and changed your directory to
     /.  The command:

          jobs -l

     would print a listing like:

          [1] + 1234  Stopped   ex file (wd: /usr/fred)

CAVEATS
     The syntax %job is not expanded to the process id of the
     job.  For this reason, commands like renice(1) will not work
     with the `%' specifiers.

     Piping the output from jobs, as in the command line ``jobs
     -l | more'', will result in no output.  The reason for this
     is that a pipeline causes all commands, including built-ins,
     to be run in a subshell.  Since job information is stored on
     a per-shell basis, a subshell will not have the same job
     information as the parent.  It is possible to get this
     information by using redirection, as in ``jobs -l > jobs.$$;
     more jobs.$$'', since redirection does not cause a subshell
     to be used to execute jobs.

SEE ALSO
     @(1csh), alias(1csh), bg(1csh), break(1csh), cd(1csh),
     chdir(1csh), continue(1csh), csh(1csh), dirs(1csh),
     echo(1csh), eval(1csh), ex(1), exec(1csh), exit(1csh),
     fg(1csh), glob(1csh), goto(1csh), hashstat(1csh),
     history(1csh), kill(1csh), limit(1csh), logout(1csh),



Printed 5/12/88                                                 2

JOBS(1CSH)              COMMAND REFERENCE              JOBS(1CSH)



     nice(1csh), nohup(1csh), notify(1csh), onintr(1csh),
     popd(1csh), pushd(1csh), rehash(1csh), renice(1),
     repeat(1csh), set(1csh), setenv(1csh), sh(1sh), shift(1csh),
     source(1csh), stop(1csh), suspend(1csh), time(1csh),
     umask(1csh), unhash(1csh), unalias(1csh), unlimit(1csh),
     unset(1csh), unsetenv(1csh), wait(1csh), which(1csh), and
     read(2).
















































Printed 5/12/88                                                 3

%%index%%
na:312,78;
sy:390,167;
de:557,2796;3737,1074;
op:4811,223;
ex:5034,353;
ca:5387,895;
se:6282,726;7392,887;
%%index%%000000000140