Google


executed after you login to the system, will, after it reads com-
mands from read commands from a file also in your home directory.
This file contains commands which you wish to do  each  time  you
login  to the UNIX system.  My file looks something like: set ig-
noreeof set mail=(/usr/spool/mail/bill) echo  "${prompt}users"  ;
users  alias  ts  \          'set  noglob  ; eval `tset -s -m di-
alup:c100rv4pna -m plugboard:?hp2621nl *`'; ts; stty intr ^C kill
^U  crt  set  time=15  history=10  msgs  -f  if  (-e  $mail) then
        echo "${prompt}mail"         mail endif  This  file  con-
tains  several commands to be executed by UNIX each time I login.
The first is a command  which  is  interpreted  directly  by  the
shell.   It sets the shell variable which causes the shell to not
log me off if I hit ^D.  Rather, I use the command to log off  of
the  system.   By  setting the variable, I ask the shell to watch
for incoming mail to me.  Every 5 minutes  the  shell  looks  for
this file and tells me if more mail has arrived there.  An alter-
native to this is to put the command biff y in place of this this
will  cause  me to be notified immediately when mail arrives, and
to be shown the first few lines of the new message.  Next  I  set
the  shell variable `time' to `15' causing the shell to automati-
cally print out statistics lines for commands which  execute  for
at  least  15 seconds of CPU time.  The variable `history' is set
to 10 indicating that I want the shell to remember  the  last  10
commands  I  type  in  its (described later).  I create an ``ts''
which executes a tset(1) command setting up the modes of the ter-
minal.   The parameters to indicate the kinds of terminal which I
usually use when not on a hardwired port.  I then execute  ``ts''
and  also use the command to change the interrupt character to ^C
and the line kill character to ^U.  I then run  the  `msgs'  pro-
gram, which provides me with any system messages which I have not
seen before; the `-f' option here prevents  it  from  telling  me
anything  if  there  are no new messages.  Finally, if my mailbox
file exists, then I run the `mail' program to  process  my  mail.
When the `mail' and `msgs' programs finish, the shell will finish
processing my file and begin reading commands from the  terminal,
prompting for each with `% '.  When I log off (by giving the com-
mand) the shell will print `logout' and execute commands from the
file `.logout' if it exists in my home directory.  After that the
shell will terminate and UNIX will log me off the system.  If the
system is not going down, I will receive a new login message.  In
any case, after the `logout' message the shell  is  committed  to
terminating  and  will  take  no  further input from my terminal.
Shell variables The shell maintains a set of  We  saw  above  the
variables  and  which  had  values  `10' and `15'.  In fact, each
shell variable has as value an array of zero or more Shell  vari-
ables  may be assigned values by the set command.  It has several
forms, the most useful of  which  was  given  above  and  is  set
name=value  Shell variables may be used to store values which are
to be used in commands later through  a  substitution  mechanism.
The  shell variables most commonly referenced are, however, those
which the shell itself refers to.   By  changing  the  values  of
these  variables  one  can  directly  affect  the behavior of the
`/usr/local'.  If we wish that all shells which we invoke to have
access to these new programs we can place the command set path=(.
/usr/ucb /bin /usr/bin /usr/local) in our file in our home direc-
tory.  Try doing this and then logging out and back in and do set
again to see that the value assigned to has changed.  Another di-
rectory  that might interest you is /usr/new, which contains many
useful user-contributed programs  provided  with  Berkeley  Unix.
One  thing you should be aware of is that the shell examines each
directory which you insert into your path  and  determines  which
commands  are  contained there.  Except for the current directory
`.', which the shell treats specially, this means  that  if  com-
mands are added to a directory in your search path after you have
started the shell, they will not  necessarily  be  found  by  the
shell.  If you wish to use a command which has been added in this
way, you should give the command rehash to the shell, which  will
cause it to recompute its internal table of command locations, so
that it will find the newly added command.  Since the  shell  has
to  look in the current directory `.' on each command, placing it
at the end of the path specification usually  works  equivalently
and  reduces  overhead.   Other useful built in variables are the
variable which shows your home  directory,  which  contains  your
current  working directory, the variable which can be set in your
file to tell the shell not to exit when it  receives  an  end-of-
file  from  a  terminal  (as described above).  The variable `ig-
noreeof' is one of several variables which  the  shell  does  not
care  about  the  value  of, only whether they are or Thus to set
this variable you simply do set ignoreeof and to unset it do  un-
set  ignoreeof  These give the variable `ignoreeof' no value, but
none is desired or required.  Finally, some other built-in  shell
variables  of use are the variables and The metasyntax > filename
which redirects the standard output of a command  will  overwrite
and destroy the previous contents of the named file.  In this way
you may accidentally overwrite a file which is valuable.  If  you
would  prefer  that the shell not overwrite files in this way you
can set noclobber in your file.  Then trying to  do  date  >  now
would  cause  a  diagnostic  if `now' existed already.  You could
type date >!  now if you really wanted to overwrite the  contents
of `now'.  The `>!' is a special metasyntax indicating that clob-
bering the file is ok.  The space between the `!'  and  the  word
`now'  is  critical here, as `!now' would be an invocation of the
mechanism, and have a totally different effect.  The shell's his-
tory list The shell can maintain a into which it places the words
of previous commands.  It is possible to use a notation to  reuse
commands  or  words  from commands in forming new commands.  This
mechanism can be used to repeat previous commands or  to  correct
minor  typing mistakes in commands.  The following figure gives a
sample session involving typical usage of the  history  mechanism
of the shell.  % cat bug.c main()

{        printf("hello); } % cc !$ cc bug.c "bug.c", line 4: new-
line in string or char constant "bug.c", line 5: syntax  error  %
ed !$ ed bug.c 29 4s/);/"&/p
try to run the C compiler on it, referring to the file  again  as
`!$',  meaning  the  last argument to the previous command.  Here
the `!' is the history mechanism  invocation  metacharacter,  and
the  `$'  stands  for the last argument, by analogy to `$' in the
editor which stands for the end of the line.   The  shell  echoed
the  command, as it would have been typed without use of the his-
tory mechanism, and then executed it.   The  compilation  yielded
error  diagnostics  so  we now run the editor on the file we were
trying to compile, fix the bug, and run  the  C  compiler  again,
this time referring to this command simply as `!c', which repeats
the last command which started with the  letter  `c'.   If  there
were other commands starting with `c' done recently we could have
said `!cc' or even `!cc:p' which would have printed the last com-
mand  starting with `cc' without executing it.  After this recom-
pilation, we ran the resulting `a.out' file, and then noting that
there  still  was  a bug, ran the editor again.  After fixing the
program we ran the C compiler again, but tacked onto the  command
an extra `-o bug' telling the compiler to place the resultant bi-
nary in the file `bug' rather than `a.out'.  In general, the his-
tory mechanisms may be used anywhere in the formation of new com-
mands and other characters may be placed  before  and  after  the
substituted  commands.  We then ran the `size' command to see how
large the binary program images we have created were, and then an
`ls  -l'  command with the same argument list, denoting the argu-
ment list `*'.  Finally we ran the program `bug' to see that  its
output is indeed correct.  To make a numbered listing of the pro-
gram we ran the `num' command on the file `bug.c'.  In  order  to
compress out blank lines in the output of `num' we ran the output
through the filter `ssp', but misspelled it as spp.   To  correct
this  we  used  a  shell substitute, placing the old text and new
text between `^' characters.  This is similar to  the  substitute
command  in  the  editor.   Finally, we repeated the same command
with `!!', but sent its output to the line  printer.   There  are
other  mechanisms  available for repeating commands.  The command
prints out a number of previous commands with  numbers  by  which
they  can  be  referenced.  There is a way to refer to a previous
command by searching for a string which appeared in it, and there
are  other, less useful, ways to select arguments to include in a
new command.  A complete description of all these  mechanisms  is
given  in the C shell manual pages in the UNIX Programmer's Manu-
al.  Aliases The shell has an mechanism which can be used to make
transformations on input commands.  This mechanism can be used to
simplify the commands you type, to supply  default  arguments  to
commands, or to perform transformations on commands and their ar-
guments.  The alias facility is  similar  to  a  macro  facility.
Some  of  the  features obtained by aliasing can be obtained also
using shell command files, but these take place  in  another  in-
stance of the shell and cannot directly affect the current shells
environment or involve commands such as which must be done in the
current  shell.   As an example, suppose that there is a new ver-
sion of the mail program on the system called `newmail' you  wish
to  use,  rather  than  the standard mail program which is called
each change directory command.  We enclosed the entire alias def-
inition  in `'' characters to prevent most substitutions from oc-
curring  and  the  character  `;'  from  being  recognized  as  a
metacharacter.   The `!' here is escaped with a `\' to prevent it
from being interpreted when the alias command is typed  in.   The
`\!*' here substitutes the entire argument list to the pre-alias-
ing command, without giving an error if there were no  arguments.
The  `;'  separating  commands  is used here to indicate that one
command is to be done and then the next.  Similarly  the  defini-
tion  alias  whois 'grep \!^ /etc/passwd' defines a command which
looks up its first argument in the password file.  The shell cur-
rently  reads  the  file  each time it starts up.  If you place a
large number of commands there, shells will tend to start slowly.
A  mechanism  for  saving the shell environment after reading the
.cshrc file and quickly restoring it is  under  development,  but
for now you should try to limit the number of aliases you have to
a reasonable number... 10 or 15 is  reasonable,  50  or  60  will
cause a noticeable delay in starting up shells, and make the sys-
tem seem sluggish when you execute commands from within the  edi-
tor  and other programs.  More redirection; >> and >& There are a
few more notations useful to the terminal  user  which  have  not
been  introduced  yet.   In addition to the standard output, com-
mands also have a which is normally directed to the terminal even
when  the  standard output is redirected to a file or a pipe.  It
is occasionally desirable to direct the diagnostic  output  along
with  the  standard output.  For instance if you want to redirect
the output of a long running command into a file and wish to have
a  record  of any error diagnostic it produces you can do command
>& file The `>&' here tells the shell to route both the  diagnos-
tic  output  and  the standard output into `file'.  Similarly you
can give the command command |& lpr to route  both  standard  and
diagnostic  output through the pipe to the line printer daemon  A
command of the form
     command >&! file
exists, and is used when is set and already exists.  Finally,  it
is  possible  to  use the form command >> file to place output at
the end of an existing file.   If is set, then an error will  re-
sult  if  does  not  exist, otherwise the shell will create if it
doesn't exist.  A form
     command >>! file
makes it not be an error for file  to  not  exist  when  is  set.
Jobs;  Background, Foreground, or Suspended When one or more com-
mands are typed together as a pipeline or as a sequence  of  com-
mands  separated  by semicolons, a single is created by the shell
consisting of these commands together as a unit.  Single commands
without  pipes  or semicolons create the simplest jobs.  Usually,
every line typed to the shell creates a  job.   Some  lines  that
create jobs (one per line) are sort < data ls -s | sort -n | head
-5 mail harold If the metacharacter `&' is typed at  the  end  of
the  commands, then the job is started as a job.  This means that
the shell does not  wait  for  it  to  complete  but  immediately
prompts  and  is  ready for another command.  The job runs at the
job is finished?  EOT [1] - Done       du > usage %  If  the  job
did not terminate normally the `Done' message might say something
else like `Killed'.  If you want the terminations  of  background
jobs to be reported at the time they occur (possibly interrupting
the output of other foreground jobs), you can set  the  variable.
In  the  previous example this would mean that the `Done' message
might have come right in the  middle  of  the  message  to  Bill.
Background  jobs  are unaffected by any signals from the keyboard
like the STOP, INTERRUPT,  or  QUIT  signals  mentioned  earlier.
Jobs  are  recorded in a table inside the shell until they termi-
nate.  In this table, the shell remembers the command names,  ar-
guments and the of all commands in the job as well as the working
directory where the job was started.  Each job in  the  table  is
either  running  with the shell waiting for it to terminate, run-
ning or Only one job can be running  in  the  foreground  at  one
time,  but  several jobs can be suspended or running in the back-
ground at once.  As each job is started, it is assigned  a  small
identifying number called the which can be used later to refer to
the job in the commands described below.  Job numbers remain  the
same  until  the job terminates and then are re-used.  When a job
is started in the background using `&', its number,  as  well  as
the  process numbers of all its (top level) commands, is typed by
the shell before prompting you for another command.  For example,
% ls -s | sort -n > usage & [2] 2034 2035 % runs the `ls' program
with the `-s' options, pipes this output into the `sort'  program
with the `-n' option which puts its output into the file `usage'.
Since the `&' was at the end of the line, these two programs were
started  together  as  a background job.  After starting the job,
the shell prints the job number in brackets (2 in this case) fol-
lowed  by  the process number of each program started in the job.
Then the shell immediates prompts for a new command, leaving  the
job  running  simultaneously.  As mentioned in section 1.8, fore-
ground jobs become by typing ^Z which sends a STOP signal to  the
currently  running  foreground  job.  A background job can become
suspended by using the command described below.   When  jobs  are
suspended  they  merely  stop  any further progress until started
again, either in the foreground or the background.  The shell no-
tices when a job becomes stopped and reports this fact, much like
it reports the termination of background  jobs.   For  foreground
jobs  this looks like % du > usage ^Z Stopped % `Stopped' message
is typed by the shell when it notices that the  program  stopped.
For  background jobs, using the command, it is % sort usage & [1]
2345 % stop %1 [1] +  Stopped  (signal)sort  usage  %  Suspending
foreground  jobs  can be very useful when you need to temporarily
change what you are doing (execute other commands) and  then  re-
turn to the suspended job.  Also, foreground jobs can be suspend-
ed and then continued as background jobs using the  command,  al-
lowing  you to continue other work and stop waiting for the fore-
ground job to finish.  Thus % du > usage ^Z Stopped % bg [1] du >
usage  & % starts `du' in the foreground, stops it before it fin-
ishes, then continues it in the background  allowing  more  fore-
ground  commands to be executed.  This is especially helpful when
(indicating the previous job); `%#', where # is the  job  number;
`%pref'  where pref is some unique prefix of the command name and
arguments of one of the jobs; or `%?'  followed  by  some  string
found  in  only  one of the jobs.  The command types the table of
jobs, giving the job number, commands and  status  (`Stopped'  or
`Running')  of  each  background or suspended job.  With the `-l'
option the process numbers are also typed.  % du >  usage  &  [1]
3398 % ls -s | sort -n > myfile & [2] 3405 % mail bill ^Z Stopped
% jobs [1] - Running    du > usage [2]    Running   ls -s |  sort
-n > myfile [3] + Stopped    mail bill % fg %ls ls -s | sort -n >
myfile % more myfile The command runs a suspended  or  background
job  in  the foreground.  It is used to restart a previously sus-
pended job or change a background job to run  in  the  foreground
(allowing  signals or input from the terminal).  In the above ex-
ample we used to change the `ls' job from the background  to  the
foreground  since we wanted to wait for it to finish before look-
ing at its output file.  The command runs a suspended job in  the
background.  It is usually used after stopping the currently run-
ning foreground job with the STOP signal.  The combination of the
STOP signal and the command changes a foreground job into a back-
ground job.  The command suspends a background job.  The  command
terminates  a  background or suspended job immediately.  In addi-
tion to jobs, it may be given process numbers  as  arguments,  as
printed  by Thus, in the example above, the running command could
have been terminated by the command % kill %1 [1]  Terminated  du
>  usage % The command (not the variable mentioned earlier) indi-
cates that the termination of a specific job should  be  reported
at  the  time it finishes instead of waiting for the next prompt.
If a job running in the background tries to read input  from  the
terminal  it  is  automatically stopped.  When such a job is then
run in the foreground, input can be given to  the  job.   If  de-
sired,  the  job  can be run in the background again until it re-
quests input again.  This is illustrated  in  the  following  se-
quence where the `s' command in the text editor might take a long
time.
% ed bigfile
120000
1,$s/thisword/thatword/
^Z
Stopped
% bg
[1] ed bigfile &
%
 . . .  some foreground commands
[1] Stopped (tty input)ed bigfile
% fg
ed bigfile
w
120000
q
%
So after the `s' command was issued, the `ed' job was stopped with ^Z
periods without interaction.  Thus each time it outputs a prompt for more
input it will stop before the prompt.  It can then be run in the
foreground using
more input can be given and, if necessary stopped and returned to
the background.  This
command might be a good thing to put in your
file if you do not like output from background jobs interrupting
your work.  It also can reduce the need for redirecting the output
of background jobs if the output is not very big:
% stty tostop
% wc hugefile &
[1] 10387
% ed text
. . . some time later
q
[1] Stopped (tty output)wc hugefile
% fg wc
wc hugefile
   13371   30123   302577
% stty -tostop
Thus after some time the `wc' command, which counts the lines, words
and characters in a file, had one line of output.  When it tried to
write this to the terminal it stopped.  By restarting it in the
foreground we allowed it to write on the terminal exactly when we were
ready to look at its output.
Programs which attempt to change the mode of the terminal will also
block, whether or not
is set, when they are not in the foreground, as
it would be very unpleasant to have a background job change the state
of the terminal.
Since the
command only prints jobs started in the currently executing shell,
it knows nothing about background jobs started in other login sessions
or within shell files.  The
can be used in this case to find out about background jobs not started
in the current shell.
Working Directories
As mentioned in section 1.6, the shell is always in a particular
The `change directory' command
(its
short form
may also be used)
changes the working directory of the shell,
that is, changes the directory you
are located in.
It is useful to make a directory for each project you wish to work on
and to place all files related to that project in that directory.
The `make directory' command,
creates a new directory.
The
(`print working directory') command
reports the absolute pathname of the working directory of the shell,
No matter where you have moved to in a directory hierarchy,
you can return to your `home' login directory by doing just
cd
with no arguments.
The name `..' always means the directory above the current one in
the hierarchy, thus
cd ..
changes the shell's working directory to the one directly above the
current one.
The name `..' can be used in any
pathname, thus,
cd ../programs
means
change to the directory `programs' contained in the directory
above the current one.
If you have several directories for different
projects under, say, your home directory,
this shorthand notation
permits you to switch easily between them.
The shell always remembers the pathname of its current working directory in
the variable
The shell can also be requested to remember the previous directory when
you change to a new working directory.  If the `push directory' command
is used in place of the
command, the shell saves the name of the current working directory
on a
before changing to the new one.
You can see this list at any time by typing the `directories'
command
% pushd newpaper/references
~/newpaper/references  ~
% pushd /usr/lib/tmac
/usr/lib/tmac  ~/newpaper/references  ~
% dirs
/usr/lib/tmac  ~/newpaper/references  ~
% popd
~/newpaper/references  ~
% popd
~
%
The list is printed in a horizontal line, reading left to right,
with a tilde (~) as
shorthand for your home directory--in this case `/usr/bill'.
The directory stack is printed whenever there is more than one
entry on it and it changes.
It is also printed by a
command.
is usually faster and more informative than
since it shows the current working directory as well as any
other directories remembered in the stack.
The
command with no argument
manual page for details.
Since the shell remembers the working directory in which each job
was started, it warns you when you might be confused by restarting
a job in the foreground which has a different working directory than the
current working directory of the shell.  Thus if you start a background
job, then change the shell's working directory and then cause the
background job to run in the foreground, the shell warns you that the
working directory of the currently running foreground job is different
from that of the shell.
% dirs -l
/mnt/bill
% cd myproject
% dirs
~/myproject
% ed prog.c
1143
^Z
Stopped
% cd ..
% ls
myproject
textfile
% fg
ed prog.c (wd: ~/myproject)
This way the shell warns you when there
is an implied change of working directory, even though no cd command was
issued.  In the above example the `ed' job was still in `/mnt/bill/project'
even though the shell had changed to `/mnt/bill'.
A similar warning is given when such a foreground job
terminates or is suspended (using the STOP signal) since
the return to the shell again implies a change of working directory.
% fg
ed prog.c (wd: ~/myproject)
 . . . after some editing
q
(wd now: ~)
%
These messages are sometimes confusing if you use programs that change
their own working directories, since the shell only remembers which
directory a job is started in, and assumes it stays there.
The `-l' option of
will type the working directory
of suspended or background jobs when it is different
from the current working directory of the shell.
Useful built-in commands
We now give a few of the useful built-in commands of the shell describing
how they are used.
The
command described above is used to assign new aliases and to show the
existing aliases.
With no arguments it prints the current aliases.
It may also be given only one argument such as
the number of the current command in the history list.
You can use this number to refer to this command in a history substitution.
Thus you could
set prompt='\! % '
Note that the `!' character had to be
here even within `'' characters.
The
command is used to restrict use of resources.
With no arguments it prints the current limitations:
cputime   unlimited
filesize  unlimited
datasize  5616 kbytes
stacksize 512 kbytes
coredumpsizeunlimited
Limits can be set, e.g.:
limit coredumpsize 128k
Most reasonable units abbreviations will work; see the
manual page for more details.
The
command can be used to terminate a login shell which has
set.
The
command causes the shell to recompute a table of where commands are
located.  This is necessary if you add a command to a directory
in the current shell's search path and wish the shell to find it,
since otherwise the hashing algorithm may tell the shell that the
command wasn't in that directory when the hash table was computed.
The
command can be used to repeat a command several times.
Thus to make 5 copies of the file
in the file
you could do
repeat 5 cat one >> five
The
command can be used
to set variables in the environment.
Thus
setenv TERM adm3a
will set the value of the environment variable TERM
to
`adm3a'.
A user program
exists which will print out the environment.
It might then show:
% printenv
HOME=/usr/bill
SHELL=/bin/csh
PATH=:/usr/ucb:/bin:/usr/bin:/usr/local
TERM=adm3a
USER=bill
%
The
     52    178   1347 /usr/bill/rc
    104    356   2694 total
0.1u 0.1s 0:00 13% 3+3k 5+3io 7pf+0w
%
indicates that the
command used a negligible amount of user time (u)
and about 1/10th of a system time (s); the elapsed time was 1 second (0:01),
there was an average memory usage of 2k bytes of program space and 1k
bytes of data space over the cpu time involved (2+1k); the program
did three disk reads and two disk writes (3+2io), and took one page fault
and was not swapped (1pf+0w).
The word count command
on the other hand used 0.1 seconds of user time and 0.1 seconds of system
time in less than a second of elapsed time.
The percentage `13%' indicates that over the period when it was active
the command `wc' used an average of 13 percent of the available CPU
cycles of the machine.
The
and
commands can be used
to remove aliases and variable definitions from the shell, and
removes variables from the environment.
What else?
This concludes the basic discussion of the shell for terminal users.
There are more features of the shell to be discussed here, and all
features of the shell are discussed in its manual pages.
One useful feature which is discussed later is the
built-in command which can be used to run the same command
sequence with a number of different arguments.
If you intend to use UNIX a lot you should look through
the rest of this document and the csh manual pages (section1) to become familiar
with the other facilities which are available to you.









































































Man(1) output converted with man2html