@device(imprint10)
@make(report)
@definefont(Userfont, 1=<Typecase ComputerModernBold10R36>,
                      2=<Typecase ComputerModernBold10R14>,
                      3=<Typecase ComputerModernBold10R9>)
@modify(CopyrightNotice, Fixed -1 inch, Flushright)
@Modify(Titlebox, Fixed 2.5 inches)
@Style(Font computermodernroman11)
@Style(spacing 1,indent 0)
@Style(leftmargin 1.0inch)
@Style(Linewidth 6.5inches)
@begin(Titlepage)
@Blankspace(2 inch)
@begin(MajorHeading,Flushright,Font Userfont, FaceCode 1)
Essential Unix
@end(Majorheading)
@blankspace(1 inch)
@begin(flushright, Font Userfont, FaceCode 2)
L. B. Merims
MIT Project Athena
Revision A
September 4, 1984
@end(flushright)
@CopyrightNotice(Massachusetts Institute of Technology)
@end(titlepage)
@Begin(MajorHeading,Flushright)
Essential Unix
@end(majorheading)
@blankspace(2 inch)


@section(Introduction)

@p(Essential Unix) explains the dozen things that you have to know to
get through a typical Unix session:  those commands that, although they
make up only 5% of the total commands available to you, are the commands
that you use 80% of the time.  When you have finished reading @i(Essential
Unix), you will know:
@begin(itemize)
  how to login and logout;

  what control keys to press to delete a character or bail out of
  a program;

  how to get help

  the Unix command format

  how to manage Unix files, including how to create them,
  display them, get lists of them, print
  them on a line printer, delete them, and control who uses them;

  what directories are and how to move around them;

  a bit about how to explore and control your Unix environment; and

  how to recognize some of the typical traps that everybody always
  falls into when they start to use Unix
@end(itemize)

Like its companion documents in Athena's "Essential" series:
@I(Essential Athena, Essential Emacs,) and
@i(Essential Mail, Essential Unix)'s  purpose is to get
you on the system and started as quickly as possible.
Less basic, but important Unix concepts
such as "pipes" and "redirection" will be ignored or mentioned only
in passing because they are not survival material.
@newpage
@section(First You Need...)

To use the Project Athena system, you need to know all of the things
on the list below.  Your project or course Account Administrator should
supply you will all of this information.  If you have questions
about any of this, for example, "What's an Account Administrator?"
see the companion document @i(Essential Athena).

@begin(description)
your Unix username and
password@\You login to the system with your @b(username) and @b(password).  
(Usernames are also referred to as "login ids," "accounts," "userids"
and "numbers".)  The username
is up to eight characters long.  Unless you asked for something different,
it will be your first and middle initials followed by as
much of your last name as will fit in the eight character limit.
Usernames are always in all-lowercase letters.
 
your assigned host machine and
terminal cluster room number@\Your username will 
only work on the host machine assigned to you.
Usually, all terminals in a terminal cluster can reach your host machine.

the combination to the terminal cluster door
@\The cluster terminal
rooms are normally locked.
Enter the combination on the electronic lock next to the terminal door.
@end(description)



@newpage
@section(Login)

Go to your assigned terminal cluster.  All of the terminals
in the clusters have little signs on them that say what host machine
they are connected to, their tty (port) address, and what
kind of terminal they are.  In spite of which host a terminal is
labelled with, you can usually reach your host through any terminal.

There are currently six kinds of Athena terminals:
@begin(description)
DEC VT100@\Most of the terminals are VT100's.  Go by the Athena
               sign, @i(not) by the manufacturer's tag on the
               face of the terminal.  VT100's cannot do graphics.

IBM PC/XT@\These are microcomputers acting as terminals.  The PC's
cannot do graphics.

DEC PRO 350@\These are actually microcomputers acting as terminals.
They can do graphics.

DEC VT125@\These look just like the VT100's except that they can do
             graphics.  Again, go by
             the Athena sign, not by the manufacturer's tag.  DO NOT
             use the VT125 terminals unless you are doing graphics
             output work.  They do not work right in other situations,
             such as with the Emacs text editor.

DEC VT240@\These terminals can do graphics.

DEC VS100@\The VS100's are high-resolution
 bit-mapped graphics terminals.
@end(description)
Athena also has a limited number of 1200 baud dial-up phone lines.
The phone number is (25)8-7211.  Your modem must speak the Bell 212a
protocol; Vadic is not recognized.  There are a lot of complications
that arise when you dial-in to Athena
that are too lengthly to explain here.  See the
free Athena document @i(Dial-Up Access) if you plan to dial-in to
Athena.

Find a terminal and turn it on.
The PRO 350 and IBM PC/XT's
should behave like any other terminal when you turn them on.  If
they don't, see the connection instructions that are taped to their
main system box.


Once the terminal is on, hit the terminal's RETURN key several times
until you see the login server banner:
@example[
   Project Athena Login Server (mit-zeus on tty01)
   8:35 p.m. on Monday, 2 Jul 1984

   Machine name:
]
You want to start out with this banner.  If the terminal is already
asking 
you "Login:" then type
CTRL-D or CTRL-C several times to return it to the banner..   @foot{to enter a
"control character" (described in documentation as CTRL-c, or control-c,
or just ^c), find the key labeled CTRL on the keyboard, hold it down,
and while still holding it down, enter the second character.  In other
words, you use CTRL just
like a SHIFT key.}

Type in the name of your assigned host (home) machine in all lowercase
letters and press RETURN.  Next the system will prompt you for your
username.  Type in your username in all-lowercase
and press RETURN.  Then enter your password, followed by RETURN.
Notice that your password is not @B(echoed) (shown on the screen)
when you type it.

If all goes well, there should be a pause, and then you will see
something like:
@example[
Project Athena Login Server (mit-zeus on tty01)
8:35 p.m. on Monday, 2 Jul 1984

Machine name: hera              <----type your host machine
mit-hera Login: yourlogin       <----type your username
Password:                       <----type your password

Last login:  Fri Aug 30 14:07:04 on tty05
4.2 BSD Unix #44:  Thur Aug 29  17:28:18 EST 1984


Welcome to Project Athena
]

There will be another long pause, the screen will clear (go blank),
and then you will see something like:
@example[
Predestination was doomed from the start.
host%
]
The first "welcome" screen shows miscellaneous system information
such as the last time you logged in, what version of the system is
running, and any broadcast messages that Athena wants everybody to
see.  If there is personal mail waiting for you, you will see the
an additional "You have mail" message at the bottom of the screen.

The second screen starts off with a "fortune" that changes each
time you login.  If there is system news that Athena wants you
to look at, then you will see an additional line, "There are system messages."

The last line
is the Unix system prompt.  When you reach this point,
you are successfully logged in.  The first part of the prompt is
the host system you are on, the second part is just a % sign.
Whenever you see this prompt it means that the system is waiting
for you to type commands.  When you are logging in,
if you type anything before
the system prompt appears it is ignored.
@subsection(Problems Logging In)
@begin(description)
@multiple[
@i(Problem:)@\@i(After I typed in my username and hit RETURN it just
          sat there for a long time.)

          Sometimes the system is just very slow.
          However, if you eventually get a "Connection timed out"
          message, then either your host machine or the connection to it is
          down.  Talk to a consultant.
]

@multiple[
@i(Problem:)@\@i(Unix just prints "login incorrect.")

          This could be several things.  First, are you sure you
          are talking to the right host?  Did you enter a machine
          name first, or just respond to a "login:" prompt?  Enter 
          CTRL-D or CTRL-C and start over.

          Next, did you specify your username and password exactly
          right (no embedded blanks) as the Account Administrator
          gave it to you?  To try again, just hit RETURN until
          the "login:" prompt reappears.  If you still can't get
          on, ask a consultant for help.
]

@multiple[
@i(Problem:)@\@i(\EVERYTHING IS IN UPPERCASE WITH \BACKSLASHES IN IT, EVEN
         THOUGH \I'M NOT TYPING IN UPPERCASE.)

         When you first logged in, you typed your username in all
         uppercase.  (Maybe the CAPS LOCK key was down by mistake.)
         Unix has decided that your terminal can only understand
         all-uppercase letters, so that is all it is sending you.
         The only fix is to logout, and log back in making sure
         you give your username in all lowercase.
]
@end(description)

@newpage
@section(Logout)

You must always explicitly logout of your Unix session.  You cannot
just turn off the terminal and walk away; you will still be logged in.
The next person who turns on the same terminal will be logged in as you.

To logout of Unix, type the command @p(logout) in response to the
host% prompt.  (Athena has disabled the CTRL-D logout that works on
some Unix systems.)

If your terminal has been idle for about an hour, Unix will log you
out automatically, but only if you were not "in" some facility.

After you have logged out, please leave the terminal turned on.
@subsection(Problems Logging Out)
@begin(description)
@multiple[
@i(Problem:)@\@i(The system says "There are stopped jobs" and
 doesn't log me out.)

There is a reason for this, but it is too involved to explain here.
Just type @i(logout) again two or three times and Unix will give up
and let you go.
] 

@multiple[
@i(Problem:)@\@i(The system says "Not login shell" and won't let me
out.)

Again, without really explaining what's happening, just type
the @i(exit) command, then the @i(logout) command.  Try this
exit logout sequence several times until it works.
]

@multiple[
@i(Problem:)@\@i(I am completely stuck and just want to get out.)

It is easy to get very stuck on Unix.  In the next section,
"You Have to Know..." we describe a series of "bail out" commands
that you can try to get out of programs.  Here is a sequence that
has about an 80% chance of logging you off completely no matter
how stuck you are:
@display{
Press the RETURN key
type in a ~.   (a tilde character followed by a period)
and press the RETURN key again
}
This will not work when the terminal you are using is connected
directly to your real host machine.  As a last resort, you must kill
a stuck terminal session from a different terminal.  See the section
below "To Kill a Session."
]
@end(description)

@newpage
@section(You Have to Know...)

Once you see the @i(host%) prompt, you are logged in and ready to enter
commands.  However, before we start describing Unix commands,
there are a few general facts about the system that you have to know.


@subsection(Control Keys:  Fixing Typos, Bailing Out)

Unix, like other computer systems, has a set of keystrokes that you
use to signal conditions that commonly occur as you enter commands
and converse with the system.  The main ones are:

@begin(description)
To backup and correct a typing mistake in a command line:@\the DELETE
key.  The BACKSPACE (CTRL-H, or ^H key) does not delete.  Use
the DELETE key.  On PRO350, PC/XT, VS100, and VT240 terminals, the DELETE
key isn't labeled "DELETE."  Instead, it is in the upper right corner
of the keyboard just above the RETURN key.
In Unix parlance, this is called the "erase" character.

To cancel a whole line and start over:@\CTRL-U.  The whole line will
disappear.
In Unix, this is called the "kill" character.

@multiple[
To bail out of any program, cancel a command in progress, "get me
out of here," "forget it," "stop!":@\CTRL-C.
CTRL-C usually works.  If one doesn't work, try entering several
CTRL-C's in a row.  Some programs do not follow system conventions and
CTRL-C doesn't work.  A good first alternative to try is q (short
for quit).  After that, try exit, RETURN CTRL-D, or CTRL-Y, or CTRL-Z.

If you are really stuck, see a consultant.  Turning off the terminal
does not log you out.
]

Pause and restart displays@\
The CTRL-S, CTRL-Q pause/restart characters that some of you may be
familiar with do not usually work on Project Athena terminals.  The NOSCROLL
key will appear to work, but it is really isn't.  For a substitute,
see the discussion of @i(more) in the "Files" section.
@end(description)

@subsection(Case Sensitivity)

Unix is unusual among operating systems because it is case-sensitive:
it matters
whether you type a letter in upper- or lowercase.
The command to list files is ls, not LS.  The file readme is
different from the file Readme, which is different again from the file
README.  The command option -p is different from the command option
-P.  You must train your eye to pay attention to the case of
letters and always mimic exactly what you see.

Most things in Unix are entered in all-lowercase, like e.e. cummings.
Uppercase tends to be used to make something really stand
out, or when the lowercase alternative is already being used for
something else.

Unix's case sensitivity causes a lot of confusion and it is a
matter of debate as to
whether it is really a "good" feature.  Nonetheless, it is the way the
system works.


@subsection(Common Terminal Session Problems)

Here are a few problems that you are likely to run into as you use
the system:
@begin(description)
@multiple[
@i(Problem:)@\@i(Everything is dead.  Nothing I type shows up on the screen,
         not even RETURN or CTRL-C.)

         This is usually one of four things, in order of frequency:
@begin(enumerate)
You accidentally hit the NO SCROLL key on a VT100 or VT125
             terminal keyboard in the lower left corner near the
             SHIFT and CTRL keys.  This tells the terminal to stop
             showing you anything.
             To start things up again, type CTRL-Q.

Your terminal settings have somehow become confused.
             Turn the terminal off, then on again.

Your host machine really is @b(down) (off or broken).  To verify
             this, ask your neighbors how they're doing.  Try to
             login from a different terminal.  If you get no response
there, too, then tell
             the consultant on duty.  If no consultant is present,
             call the Athena Hardware Hotline (25)3-1410.

Your keyboard has become locked.  This often happens on VT100 and VT125 terminals
             if you try to list out a binary file on the terminal,
             or any other un-printable file by mistake.  Hit a few
             keys and then see if
             the KBD LOCKED light above the "5" key is lit.  If
             it is, press the SET-UP key slowly twice.  This usually
             clears the condition.


@end(enumerate)
]
@end(description)

@newpage
@section(Entering Commands)


@subsection(The Shell)


You are now logged in talking to Unix.  Well...not exactly.  What you
are actually talking to is one particular Unix program (among hundreds)
called the @b(shell).  The shell is a @b(command interpreter).  This
means that the shell is the Unix program that sits on the other end of
the line listening to what you type, figures out what program
(command) you want to run, and starts it up for you.  When the program
finishes, the shell comes back and asks for the next command with
another host% prompt.

On Unix, you can choose from among several shells.
Normally, you
use the @b(C shell) written at UC Berkeley.  The actual name of the C shell
program is @I(csh).  The C shell prompt always ends with the
percent sign (%).  There is also an older shell, called the @b(Bourne shell),
that was originally written at Bell
Labs. The name
of the Bourne shell is @i(sh). @foot{Athena is actually using
yet a third shell, called @I(newshell).  This newshell is identical to
the Berkeley C shell except that it includes some additional
convenient features
like those found in the Tops-20 operating system such as automatic file
name completion when you hit the ESC key.
For most people, the differences are unimportant and can be ignored.  
But, if you care about this, read the newshell page in the
Athena Unix Commands manual, or enter @i(man newshell).}

The C shell is a very powerful program, most of whose abilities are
beyond the scope of this document.  You can use it, for example, to
run more than one program at a time.  The C shell is explained fully
in @i(An Introduction to the C Shell.)  This is for sale at the IPS
Publications Office in 11-209 for a few dollars.  It is also included
in the Athena Unix User's Guide.  To read the
online information (16 pages' worth)
about the C Shell type @i(man csh).

For now, the important thing to know is that the shell is your
intermediary to the Unix system and its programs.


@subsection(Command Format)

The general form of a Unix command is:
@display[
     @I(command)   @i(options)   @i(files)
]

@b(Command)

Unix @b(commands) are entered in all lowercase.  You cannot abbreviate command
names.  There are currently about 250 Unix commands.  A Unix "command" is
really nothing more than the name of a program.

If you mistype a command name, the shell responds "Command not found."

@b(Options)

@b(Options) are the "adjectives and adverbs";
they modify the way that the command
works, for example, "Show me all of them instead of just some," or "send it
to that printer instead of the usual one."  You will also see options called
"arguments," "flags," "qualifiers," and "switches" depending upon the
operating system background of the person talking.

Unfortunately, Unix commands are very inconsistent about they way they let
you specify options.  Usually:
@display[
you start them with a - (hyphen or minus) sign

options are: single letters  (-a)
             single letters followed by a value  (-P printer)
             in some newer programs, options are complete words (-draft)

you can run all the single letter options together first:  lpr -hf

followed by all the options with values separated by blanks:  lpr -hf  -P laser
]
The only way to be sure about how a command will interpret the borderline
cases of its options is to look at the documentation for that command
and experiment.  @i(Essential Unix) shows you one form of the commands
that works.

If you make a mistake in the options of a command, the program will
show you the correct general command syntax.

@b(Files)

the files that you want the command to work on

If there is something wrong with the file specification, Unix usually
replies: filename not found, or filename:  cannot open, or filename:
no such file or directory.

Separate these three pieces of a command with blanks.  End commands by 
pressing RETURN.


@newpage
@section(Change Your Password: passwd)

To protect your work and privacy, you should change your password often.
To change your password, type the Unix command @i(passwd).  Passwd will
prompt for your old password, then ask you twice for your new password.
Neither your old nor your new passwords will show on the screen as
you type them:
@example[
host% passwd
Changing passwd for yourlogin
Old password:                      <--- you enter it invisibly
New password:                      <--- you enter it invisibly
Retype new password:               <--- enter it again
host% 
]
If you try to pick a password that is less than five characters
long, Unix will complain.  If you really want the short
password, insist three times and Unix will give up and let you have
your way.


@newpage
@section(Getting Help)

@subsection(Documentation: man and apropos)

Unix keeps a massive amount of information about itself available
"online."  Indeed, the entire Unix Programmer's Manual--what
Project Athena sells as its @i(Commands, Functions, User's) and
@i(Programmer's) guides--is available online.

There are two commands that let you access this information, @i(man)
and @i(apropos).  You use @I(man) when you know the command you want to use
and just want to refresh your memory about its options.  You use
@i(apropos) when you know what you want to do, but you don't know
what commands, if any, do it.

The format of the man command is:
@display[
host% man @i(command)
]
@i(man) will look for documentation on that command.
If it finds it, it displays it on your terminal screen.
The NAME section gives a one-line summary of what the command is.
The SYNOPSIS section shows you how to enter the command.  You
don't type the [] characters.  These only mean that the option
can be ommitted.  The DESCRIPTION section explains the command and
its options in greater detail.

To get man to go on to the next page, hit the SPACEBAR.  When you've
seen enough, enter q or CTRL-C.

@i(man) takes some getting used to.  First, you may have trouble understanding
the information.  Most of it was written by programmers for programmers.
It tends to define rather than explain. 

Next, @i(man) contains many entries that are not commands.  @i(Man) has
8 sections; only section (1) is commands.  The rest
are:
@display[system calls (2)
subroutine libraries (3)
I/O devices (4)
files (5)
games (6)
odds 'n ends (7)
system manager tools (8)
]
Sometimes you may think you've found a command and try to
execute it when what you've really found is the name of a Fortran
subroutine.  The top line of the man page tells you what section
you're looking at.

The format of apropos is:
@display[
host% apropos @i(keyword)
]
where @I(keyword) is any word you can think of that might describe what
you're looking for.  @i(apropos) searches the one-line descriptions
of the manual pages looking for the keyword.  It them prints all
the matches it has found.  You then use @i(man) to look at the actual
entries.

@i(apropos) also takes some getting used to.  You don't usually find
what you want on the first try.  You often fail to find it altogether.
Pick your keywords broadly.  "File" is a good desperation choice.

You can get apropos to list all the entries in a given section
of the manual.  To list all the games, for example, say:
@example[
host%  apropos '(6)'
]
Practice using @I(man) and @I(apropos).  They are a mainstay of a Unix
user's life.  We assume that you will "look at the man page"
for every command introduced in @i(Essential Unix) to learn more
about the way it works.

More online Unix documentation is kept in the tree of files
and directories beneath @i(/usr/doc).  (Directores are explained
in a later section.)  The free Athena document @i(Start Here)
catalogs all the printed documentation available.


@subsection(Consultants)

If you have a question about Unix, the best first strategy is to
ask the person next to you.  Unix has a very strong oral folklore.

Most Athena clusters are staffed by student consultants during the day.
They will be wearing a hat
decorated with an underground version of the Athena owl and the words
"Athena Consultant."
Student consultants can answer general questions about the system,
but cannot be expected to know the nooks and crannies of every compiler
and package on the system.


@subsection(Hardware Trouble)

If you think there is a hardware malfunction, first seek out a
consultant to analyze the situation.  It usually isn't hardware.
If no consultant is available, call the Athena Hardware Hotline
(25)3-1410.



@newpage
@section(Files)



In the small, self-contained
Unix universe, the most popular topic of conversation
is files.  A @b(file) is just a thing with a name and data in it.
Most things that you do, you do to files or their contents.
There are two main types of files, simple files and @b(directories).
We will begin by discussing simple files and leave directories
until the next section.

@subsection(File Names)

File names can be from one to 256 characters long.  You can use any character
on the keyboard 
except a / (slash) in a file name, but it is wisest to stick to a-z, A-Z,
0-9 and the . (period or "dot"), and _ (underscore) characters.  If you
use any of the other characters, you may be letting yourself in for
serious trouble.  As noted earlier, case matters in file names. 
myfile is a different file from Myfile.


@b(File Naming Conventions)

You often see Unix files named with @b(extensions), for example:
@i(program.h, paper.mss).  The ".xxx" is the extension.
People do this for two reasons.  First, 
to remind themselves what type of file it is.
A @i(.h) file is a C language "include" file.  A @i(.mss) file is a
Scribe text formatter file.  Second, because some Unix programs,
notably the compilers, require that language source files
have proper extensions;  @i(.c) for C, @i(.f)
for Fortran, and @i(.p) for Pascal.

Some file names start with a . (dot), e.g., @i(.cshrc) or @i(.login).  The
only significance to this is that these files do not normally show
up when you ask for a list of your files.  Background, utility,
"start up" files are named beginning with ..  Some examples of these
"dot files"
are discussed below in the section "Exploring Your Environment."


@b(Wildcards:  * and ?)

Unix provides a shorthand notation for referring to many files
at once called @b(wildcard characters).
Here are the two most useful wildcard characters:
@begin(description)
*@\Matches all files except those whose names begin with @b(.) (dot).
   It can also match characters within a filename.  For example,
   @i(*.f) means "all the files with a .f extension."  @i(h.f) and
   @i(verylongfilename.f) would both match.  @i(a*) means "all the files
   that begin with a"  File names @i(a) and @i(anothernameforyou) would
   both match.

?@\Matches single characters.  @i(?.f) means all one character file
   names with extensions of @i(.f).  @i(a.f) would match.  @i(ab.f) would not.
@end(description)
The section on "Directories" has examples of wildcard characters in use.


@subsection(Get a List of Your Files:  ls)

The command to get a list of the files in a directory is @p(ls).

If you are a new Athena user and you type @i(ls), this is roughly what
you will see:
@example[
host%  ls
Mail    welcome
]
@i(ls) by itself lists just the files names, alphabetically (A-Z before
a-z) in as many columns as will fit across the screen.

The @i(ls) command has many options.  To see all the options, enter
man ls while logged in at a terminal.  Here are the most important
options.

To get a list of all of the files in a directory, including those
whose names begin with a @b(.) (dot) character, use the @p(-a) option
(for "all").  A new user doing this would see something like:
@example[
host%  ls -a
.        .emacs_keys       .logout       .tiprc
..       .emacs_vars       .mailrc       Mail
.cshrc   .login            .mh_profile   welcome
]
The difference, then, is that @i(ls) doesn't show the files whose names begin
with ., and @i(ls -a) does.  Just what all these files are is explained
below under "The Files that Come with Your Username" in the
"Exploring Your Environment" section.

To get a "long" listing of your files that shows much more information about
them, use @p(ls -l).
@example[
host%  ls -l
drwx--x--x  1 you         2 Nov  3  1983 Mail
-rw-------  1 you         0 Nov  3  1983 mbox
-rw-r--r--  1 you       404 Nov 27  1983 welcome
]
The first set of information on the line is the file's @b(mode).
A "d" in the first column means that the file is a directory.
The r's and x's that follow show who has permission to read, 
write, delete, and execute the file.  This is explained in more
detail in the section on "File Protection" below.

The second column shows the number of "links" the file has.  We won't
explain links here.  For directories, it shows how many subdirectories
exist beneath the file.  There are always at least two.

The third column shows the username of the user who
owns the file.  In most cases this should be your username.

The fourth column column shows the size of the file in "bytes."
In a text file, this is the number of characters in the file.

The fifth column shows the date when the file was last modified.
If a file has never been modified, it shows the date it was created.

The final column shows the name of the file.

You can use other options on the ls command to get it to show
you other information about your files.

To get a long listing of all the files in a directory, you would
enter @i(ls -la).

There are different types of files:  text files, files that are
directories to more files, and executable binary files.  Often,
you need to know the type of the files being listed.  The @p(-F)
(note, @i(uppercase) F) will show this:
@example[
host%  ls -F
Mail/    a.out*   myfortpgm.f   welcome
]
Notice the suffix characters / and * that are now displayed.  These
characters are NOT part of the filename.  The / character means
that the file is a directory.  The * character means that the file
is an executable binary or a shell script.
Nothing means either a plain text file,
or that Unix cannot recognize the type of the file.


@subsection(To See the Contents of a File:  cat and more)

There are two commands that will show you what's in a file.  The
simplest is the @p(cat) command (short for "catenate").  The format
of the commands is:  cat @i(filename).  For example:
@example[
host%  cat .login
stty dec 
setenv PATH /usr/athena:/usr/new:/usr/new/mh:
            /usr/ucb:/bin:/usr/bin:/usr/local:~/Bin:/usr/games:/usr/hosts
setenv VISUAL /usr/athena/xemacs
setenv EDITOR /usr/athena/xemacs
setenv MORE -cs
set ignoreeof
host%
]
The contents of the file are shown on the screen.  If the file is very
long, it will zip by you on the screen faster than you can read it.
(CTRL-S and CTRL-Q usually don't work.)  In this case you should probably use
the @p(more) command instead of @i(cat).  To cancel a @i(cat) command
and stop its output at any time, enter CTRL-C.
@begin(description)
@multiple[
@i(Problem:)@\@i(I "catted" a file, but I got a lot of gobble-dee-gook and
          the terminal acted stranged, beeping a lot.)

          Some kinds of files are "unprintable."  They contain data in
          a format that cannot be displayed on a terminal screen.
          @p(Binary) files (the ones @i(ls -F) shows with a * suffix) are
          not printable.  @p(Directory) files (@i(ls -F) shows with / suffix)
          are not very printable.  It is very common when you start
          out to say @i(ls) when you meant @i(cat) and @i(cat)
          when you meant @i(ls).
]
@end(description)

The @p(more) command displays a file's contents one screen at a time,
pausing after every screenful so that you can read it.  The format
is:
@display[
host%  more @i(filename)
]
Most people use @i(more) in preference to @i(cat).

Once @i(more) has filled up a screen, it will not display more
until you make it.
The typical commands are:
@display[
SPACEBAR     give me the next screenful
RETURN       give me one more line
q or CTRL-C  quit, I've seen enough
]
Alas, @i(more) cannot back up.

@i(More) is a very interesting program.  If one were making an "all-time
Top-10" list of Unix commands, @i(more) would be near the top.  It is
clever enough not to display binary and directory file.  There
are subcommands to browse through a file for specific
words, or invoke a text editor to edit the file.

Most interesting is that @i(more) is what is called a Unix @b(filter).
Many other Unix commands @b(pipe) their output through more.  This
means that instead of giving you their output directly--where
it may zip past faster than you can read it the way @i(cat) does--
they send it through @i(more) first so that it will be easy to read
under your control.  The @i(man) command does this.

You, too, can "pipe things through more."  Whenever you enter a
command and its output is too copious and rapid to manage, cancel
the command with CTRL-C and reenter it like this:  
@example[
host% command | more
]
The | is the "pipe" character.  For example, if you have collected
hundreds of files, you could pipe the output of @i(ls) through @i(more):
@example[
host%  ls -l | more
]
Look at @i(man more) to learn more about its powers.


@subsection(Create a File)

There are many ways to create a file.  The normal way to create a file
is with the @B(emacs) text editor.  The free Athena document @I(Essential
Emacs), explains how to do this.

A "quick and dirty" way to create a file is with the @i(cat) command
It works as follows. 
@example[
host%  cat >easyfile
Unix just moves the cursor down to the
next line.  You begin to type.  End each line
with a RETURN.  You can fix typing mistakes
with the DELETE key in the line you are currently
typing.  You can erase the whole line you are
typing currently with CTRL-U.
There is no way to fix previous lines.
When you are done, finish the last line with
a RETURN and then at the beginning of the next
line enter just CTRL-D.  It echoes as ^D.
^D
host%
]
There is no way to fix mistakes in this file short of deleting it and 
re-entering the whole thing.  @b(Don't forget the @i(>filename) part.)
If you do, @i(cat) will just echo your input to the terminal and
create no new files.  The @i(>filename) is what tells @i(cat) to
save it as a file instead.

You can take the output of any Unix command and put it into a
file.  For example, the command that shows you what electronic
mail messages you have is @p(scan):
@example[
host%  scan
102   2/10   cec (Cecilia d'O  Re: IPS educational and consulting 
104   2/10   jg (Jim Gettys)   UUCP outgoing mail.  <<Now works p
105   2/10   cec (Cecilia d'O  DEC Orientation Meeting Agenda
109   2/12   gary (Gary McDon  bldg 1 printers  <<The LN01 and th
]
When you enter this command, the output from the command is
displayed on the screen.  If for some reason you wanted to save what you
were seeing on the screen in a file, you could @b(redirect) the
output of the command into a file:
@example[
host%  scan >mymail
host%  ls
Mail  easyfile  mymail  welcome
]
The ">filename" at the end of the command line is the redirection
mechanism.  Be sure your arrow is pointing the right way.  It is
all right to have a blank between the > and the filename you
have selected.  The "quick
and dirty" mechanism shown above is really just redirecting the
output of the @i(cat) command to a file.


@subsection(Delete a File)

It is a good idea to delete files as soon as you know you won't
be needing them anymore.  Otherwise, your directory can become
very cluttered and you will eventually run out of your alotted
file storage quota and begin to have problems.

The command to delete a file is @p(rm) (short for "remove"):
@example[
host%  rm easyfile 
host%
]
Unix doesn't verify the deletion, it just prompts for the next command.
You can put more than one name on the line.  You can use wildcards
(with caution!) to delete whole classes of files.  The most
catastrophic mistake you are likely to make is:
@display[
host% rm *
]
which deletes @b(all) your files!

@subsection(Copy a File)

The @p(cp) command copies files:
@example[
host%  cp  fromfile tofile
host%
]
Unix copies from the existing @i(fromfile) to the new @i(tofile).
If @i(tofile)
already
exists, it will be overwritten.  Again, Unix does not verify the copy.
Copies from one machine to another work slightly differently.  See
the section below on "Dealing with Other Machines."


@subsection[Rename (Move) a File]

To rename or move a file, use the @p(mv) command:
@example[
host%  mv fromfile tofile
host%
]
Unix renames @i(fromfile) to @i(tofile), in effect "moving" it from one file
to another.  If @i(tofile) already exists, it is overwritten.  As ever,
Unix does not confirm that it has done the operation.


@newpage
@section(Printed Output)


Printed output is a copy of a file on paper.  Each Athena cluster
has at least one printer, a @b(laser) printer.  Some clusters
also have a @b(line) printer.  A
large sign posted in the cluster terminal room tells you where
the printers for that cluster are, and any combination you may
need to get into the printer room.  In some clusters, the printers
are in the same room as the terminals.

The laser printer is the @b(default).
This means that if you don't specify which printer you want to
print on, the laser printer will be used.
Laser printer output is on 
8 1/2 x 11 cut sheet paper with 66 lines to the page and approximately
80 columns across.  The font is a 10-character to the inch, fixed-width
typewriter-like style called "Courier."  This is currently the only
font available, there are no italics, and no boldface.
The laser printer produces about 6 pages per minute
and has a limited paper capacity.
@begin(description)
@multiple{
@i(Problem:)@\@i[very long input lines (>140 characters) such as might
 be produced by repeated backspaces and underlines during a Scribe
 run can confuse the laser printer.]

  The only fix for this is to
 change your Scribe source to not produce so many underlines.
}
@end(description)
The line printer prints on 11 x 15 continuous form computer paper
with 66 lines to the page, and 132 columns across.  The font is a 10 
character to the inch, fixed width, sans-serif style.  The printer
can do overstriking for boldface type.  Print quality is poorer
than the laser printer. 


@subsection(Send a File to the Printer:  lpr)

The @p(lpr) command (short for "line printer") sends a copy
of a file to the printer.  The general form of the command is:
@display{
lpr  [-P  @i(printer)]  @i(filename)
}
The [] are @b(not) part of the command.  Rather, they mean that the
@i(-P printer) option is optional and can be ommited if you like.

The @i(-P) option states which printer you want the file(s) sent
to.  The choices are:
@begin(description)
-P laser@\this is the default printer.  It sends the file
            to the laser printer for your cluster.

-P line@\the line printer for your cluster.

-P alternate@\each cluster has a laser printer for a different
               cluster designated as an alternate printer in
               case your cluster's printer is down, or out of
               paper, or excessively busy.  The alternate printer
               location should be posted in the cluster.
@end(description)
@i(lpr) does not verify that it has sent your file(s) to the printer.
The @i(lpr) command has many options (not all of which work).  Type
@i(man lpr) to see the choices.  Also, the @i(lpr) command does not
always tell you when you have made a mistake in its options, it
just ignores the options it could not handle.

You may notice two other possible candidates for commands to
send output to the line printer, @p(print) and @p(pr).  @i(print) is an
old command that has been superceded by @i(lpr).  In spite of what
the documentation seems to say, the @i(pr) command doesn't print
anything.  Rather, it is useful for doing minor formatting
of output files, such as producing a 2-column format, or adding
page numbers and headers, before you actually print the file with
the @i(lpr) command.  The @i(lpr) command does have an option
(@p[-p]) that allows you to run your files through @i(pr) on the way to
the line printer, but not all of @i(pr)'s options work when called
this way.

@subsection(What Files Are Waiting to Print:  lpq)

When you send a file to the printer with @i(lpr), the file actually is
assigned a @b(job number) and goes into a @b(queue)
before it is printed.  If there are files ahead of it in line, sent
by other users, then it waits its turn to print.
If there are none ahead of it in line, it will print immediately
(unless the printer is broken).  Very often, you will want to look at
this printer queue to see what's happening with your print job,
or to find out your print job's number so that you can cancel it.  
The command to do this is:
@example{
lpq  [-P printer]
}
@p(lpq)  is short for "line printer queue"

-P @i(printer)  has the same meaning it had for lpr.  It specifies
which printer queue you want to see.  
There is a separate queue for each printer.
@i(-P laser) is the default.
@i(-P line) specifies the line printer.  @i(-P alternate) shows the
queue for the alternate printer.

@i(lpq) has a few other options; see @i(man lpq).
@begin(description)
@multiple[
@i(Problem:)@\@i(I say lpq, but I don't see my print job.)

          There are two main possibilities.  The most likely
          is that your job has already printed.  Alternatively, you sent your
          output to a different printer queue with the @i(-P)
          option, but forgot to give the same @i(-P) option
          to the @i(lpq) command and you are looking at the
          wrong printer queue.
]

@multiple[
@i(Problem:)@\@i(I say lpq, and get no response at all, things are just
          dead.)

          Either the print server machine (see below)
is down, or the network
          connection to it.
]
@end(description)

@subsection(Cancel Print Jobs:  lprm)

Often you change your mind about printing a file.  Perhaps you accidentally
sent it to the line printer when you meant to send it to
the laser printer, or you gave the wrong filename.  You can cancel
a print job.  Use:
@display{
   lprm  [-P printer]  [-]  [jobnumber]
}
@p(lprm)   stands for "line printer remove"
@begin(description)
-P@i(printer)@\Remove the job from which printer queue?
@display{
                  -P  laser
                  -P  line
                  -P  alternate
}

@i(jobnumber)@\By default, @i(jobnumber) will the the number of whichever job
           is actually printing.  If this is your job, it will be removed.
           If it isn't, then you will get a "Permission denied" message.
           If your job is not actually printing, you must either use the
           - option below, or you must give an explicit job number.
           Use the @i(lpq) command to find out what the print job's number is.

-@\means remove @i(all) my jobs in the specified printer queue
@end(description)
You may get some slightly surprising messages from @i(lprm).  You should
understand that only one host in a cluster actually has printers
attached to it.  This is the @b(print server).  Print files from all
machines in the cluster are first forwarded to the print server,
then printed.  This is why you may get a printer message from,
say, mit-zeus when you are logged in to mit-hera.  For more information
on @i(lprm), see @i(man lprm).
@begin(description)
@multiple[
@i(Problem:)@\@i(The printer's out of paper.)

Reload the printer yourself from the stock at hand,
          following the instructions on the printer.
]

@multiple[
@i(Problem:)@\@i(There is no paper stock around.)

Call the Athena Hardware Hotline at (25)3-1410.
]

@multiple[
@i(Problem:)@\@i(The laser printer just sits there with an L1 error
          code.)

The laser printer shuts itself off when there is no
          activity for a length of time.  It now has to warm up
          again for about five minutes.
]
@end(description)

@newpage
@section(Interlude)

This is the end of the truly "survival" material in @i(Essential Unix).
You can do a lot of useful work with just the information presented
so far.

Probably the best thing to do now is to find the free Athena
document @I(Essential Emacs) and learn the basics of the text editor.

The sections that follow contain information that you can put off
learning about for a few days, or even weeks, but which you will probably
need to know about before too long.


@newpage
@section(Directories)


All files in the Unix system are stored in one large hierarchical
tree structure.  Everybody's files are somewhere in this tree,
occupying some sub-branch:  the system's
files, your files, other users' files,
the mail files, and the online documentation files, all are stored
in this tree.
See the picture.
@verbatim{



                                   /

                                   |
  --------------------------------------------------------------------
  |             |           |              |                         |
  |             |           |              |                         |
 /bin         /dev         /etc          /mit            ...       /usr
                                           |
                                           |
                                           |
                      ----------------------------------------
                      |   |    |    |   |    |               |
                      |   |    |    |   |    |               |
                     /a  /b   /c   /d  /e   /f       ...    /z
                                    |
                                    |
                                    |
                -----------------------------------------
                |   |   |   |   |   |   |   |   |       |
                |   |   |   |   |   |   |   |   |       |
               /a  /b  /c  /d  /e  /f  /g  /k  /h  ... /z
                                            |
                                            |
                                            |
                        --------------------------------------
                        |                 |                  |
                        |                 |                  |
                     /dkfritz          /dkjones    ...     /dkp
                        |
                        |
                        |
        -------------------------------------
        |         |           |             |
        |         |           |             |
       Mail   my1stpgm    forsally   ...  welcome



}

Learning your way around this tree structure, gaining a rough idea of what's
kept where, and knowing how to get to it, are fundamental to your understanding
of Unix.  Without it you can function, but you will always feel a little
confused, a little out of it, like a stranger in a group of old
friends who just doesn't quite ever @i(get it).

The tree structure is made possible by a special kind of file, a @b(directory
file).  A directory file is nothing but a list of pointers to other
files.  These other files can be text or binary files, but they
can also be more directory files, often called @b{subdirectories}.  These
subdirectories can, in turn, point to still more directory files down
to many levels of depth.  

Up to now we've seen only simple filenames like @i(myfile) or
@i(fortprogram.f).  A file's full name is its "given" name preceded
by the @b(path) of directories that the system must follow to reach
that file in the Unix tree structure, separated by the @b(/)
(slash) character.

Look again at the picture.  At the top of the tree is a file called 
@b(the root directory) because it roots the whole tree.  Its name
is / (just a simple slash).  Below that are a set of major
directories like @i(bin, dev, etc, mit, projects, sys,) and @i(usr).
Now look at the mit directory (proper name:  @i(/mit)).  This is the
major subtree where user's files are kept.  Below it are more
subdirectories, one for each letter of the alphabet (@i[/mit/a]).
Below each of these the same alphabetic pattern is repeated
(@i[/mit/a/a]).  Strung out underneath these doubly-alphabetized
directores are directores named after the usernames of
everyone on a particular machine.  User dkfritz has a directory
@i(/mit/d/k/dkfritz).


@subsection(The Working Directory)

We said that a file's full name is its given name preceded by
the path of directories one must follow to find it.  Why don't
you have to give the file's full name every time you specify it?
You don't because the system keeps a value for you called
the @b(working directory).  (Also known as a "default directory," or
"the current directory.")

Whenever you specify a simple filename, the system assumes that you are
talking about a file in your working directory.  A working directory
is, simply, the directory you are currently "in".  You can
change your working directory at any time.

The system provides a few short-hand synonyms for the working
directory.  A simple @B(.) (dot) used in a directory specification
means "the current working directory."

As a shorthand for "the directory above my current working
directory," the system recognizes @b(..) (two dots together).

Examples using these shorthand synonyms are given below.


@subsection(The HOME Directory)

Unix also employs the concept of a @b(HOME) directory.  This is the
beginning of your subtree on the main tree, where you store all
your files.
For user dkfritz
above, it was @i(/mit/d/k/dkfritz).  Your own HOME directory is
named according to the same pattern.  You can verify your HOME
directory by typing:  @i(printenv  HOME)

When you login, your working directory is set to be your HOME
directory.  Thus, unless you explicitly say otherwise, the
system assumes that you are always talking about your own
files stored under your HOME directory whenever you give a filename
in a command.


@b(Synonyms for HOME Directory:  ~/)

Typing out @i(/mit/d/k/dkfritz) everytime you want to discuss the HOME
directory of a user is tedious.  Unix provides shorthand synonyms
for HOME directories.

To say, "my HOME directory" type:  @b( ~/)

To say, "user dkfritz's HOME directory" type:  @b(~dkfritz)




@Subsection(Make a Directory:  mkdir)

You can make subdirectories under your HOME directory to better
organize your files:
@example[
host%  mkdir forclass
] 
will make a directory called @i(forclass) under the current directory.
Unix, as usual, will not verify that it has created the directory.


@subsection(Change the Working Directory:  cd)

You will often want to temporarily change your working directory from your
HOME directory to somewhere else on the tree.  Use the @p(cd) (for
"change directory") command.

For example, if you had just created a subdirectory @i(forclass) and
now wish to make and modify files in that directory (or "work
in" that directory, as the saying goes) you could tediously
specify those files as @i(forclass/assignment1) and @i(forclass/lectnotes).
Or, you could change your working directory to forclass and
speak of them as just @i(assignment1) and @i(lectnotes):
@example[
host%  cd forclass
]
Sometimes, you may be working in somebody else's directory, somewhere
else on the tree.  Rather than always typing out @i(/mit/o/t/otheruser),
you can just change the working directory to their HOME directory:
@example[
     host%  cd /mit/o/t/otheruser
  or host%  cd ~otheruser
]
Perhaps you've gotten curious about how Scribe works and wish to
rummage around in the Scribe database files.  You can switch to that
portion of the tree with:
@example[
host%  cd /usr/athena/lib/scribe/database
]

@Subsection(Find Out What Directory You're In:  pwd)

As you start hopping around the tree with @i(cd) commands, it is easy
to forget where you are.  You can always find out your current
working directory with @p(pwd) (print working directory).  For example:
@example[
host% cd /usr/prototype_user
host% pwd
/usr/prototype_user
]

@subsection(Return to Your HOME Directory:  cd)

The quickest way to change your working directory back to your HOME
directory, no matter where you have wandered in the tree is:
@example[
host%  cd
]
@i(cd) defaults to your HOME directory.  This is equivalent to saying
@i(cd ~/).


@subsection(Delete a Directory:  rmdir)

You cannot delete a directory unless all of the files underneath it are
gone.  This prevents you from accidentally wiping out important
subtrees with one careless command.

A quick way to delete all the files in a directory you want to get rid of
is to change to that directory with @i(cd), then:
@example[
host%  rm *
]
Be careful before you do this!  You cannot recover these files.
If the directory also has @b(.) dot files in it, you must say:
@example[
host% rm .*
]
You can then delete the directory itself.  Move out of the directory
back to the one above it, then type:
@example[
host%  rmdir dirname
]

@subsection(The -r Recursive Option)

Many commands will have a -r or -R @b(recursive) option.  When talking
about directories, recursive means "do it to this directory and
all the files and subdirectories underneath it."  @i(R) options are thus
very powerful and should be used with caution.  For example, one could
perform the two steps required to delete a directory in one step as
follows:
@example[
host%  rm -r dirname
]
Strangely, @i(-r) only works with @i(rm), not with @i(rmdir).
A sleepy programmer logged in as the user @b(root), that special all-powerful
username that system managers use to control the system, could take
out the whole file system with just:
@example[
host%  rm -r /
]
The recursive option on the @i(cp) (copy) command makes it easy to copy
entire subtrees from one place to another.  There are examples of
this in the next section.




@subsection(Sample Directory Specifications)

It takes a little practise to get the knack of correctly typing
filenames and directories so that you get the files you want.
Here are some common specifications.  All of these have synonyms
that would work just a well.
@itemize{
a directory called @i(foo) below my current one:   foo
(as in cd foo)

a file @i(stuff) in directory @i(foo) below my current one:   foo/stuff

all the files in directory @i(foo) below my current one:   foo/*

my HOME directory:  ~/

a file @i(stuff) in my HOME directory when I'm in my HOME directory:   stuff

a file @i(stuff) in my HOME directory when I'm someplace else:  ~/stuff

a file @i(stuff) in user sam's HOME directory:  ~sam/stuff

a file @i(stuff) in user sam's subdirectory @i(foo):  ~sam/foo/stuff

up one directory:  @b(..)  
(as in, pop me up one level:   cd ..)

a file @i(stuff) in the directory above me:  ../stuff

a file @i(stuff) in the directory @i(foo) in the directory above
the one I'm in:        ../foo/stuff

copy my file @I(george) into my subdirectory @i(archive):  cp george archive

copy sam's file @i(foo) into my current directory, and keep
 the same name:  cp ~sam/foo @b(.)

copy sam's file @i(foo) into my current directory, but with a
 different name:   cp ~sam/foo fromsam

copy all of the files in sam's subdirectory @i(foo), including all subtrees
 into my current directory, and keep all the names the same:
  cp -r ~sam/foo @b(.)
@end(itemize)

@begin(description)
@multiple[
@i(Problem:  ls /Mail:  Permission denied.)@\This is
one manifestation of a common mistake people make when learning
about directory specifications.  You were trying to list out
the files under your Mail directory.  Your first reaction is to feel
indignant about not being allowed to look at your own mail files.

The problem is the /  A slash at the beginning of a directory specification
means the @P(whole system's root directory).  Thus, you aren't naming your
Mail directory, you're naming a Mail directory immediatly under the
root directory.  This happens to belong to the system manager, who
doesn't want you looking at his/her mail.

Never start a directory specification with / unless you explicitly
mean one of the directories immediately below the whole system's
root directory, for example:  @i(/etc, /mit,) and @i(/usr).
]
@end(description)

@subsection(System File Organization:  An Aside)

This section on directories has emphasized talking about your own, and
possibly a neighbor's files.  but as anyone new to Boston must, over
time, construct a mental map of the city, its suburbs, squares,
T stops, restaurants, movie theatres, and points of personal interest
beyond their immediate neighborhood, so should you get an inkling
of what is kept in other parts of the Unix file system.  Here's
a nickle tour.

Start at the root directory and enter:
@example[
host%  ls -F /
]
(The @i(-F) is there to show you which files are directories, text
files, and binaries.)  You will see something like:
@example[
Mail/    etc/         mnt/             src/        u2/
bin/     lib/         projects/        src.log     usr/
boot*    lost+found/  restoresymble    staff@      vmunix*
dev/     mbox         site/            sys/        vmunix.0.11
         mit/         source/          tmp/        vmunix.0.3
]

Each of these root level directories contains different sorts of files
that the system needs to function.  There are strong historical
conventions for what goes in each of these root directories (as
well as many arbitrary exceptions).

You can look at most of these files.  Except for parts of 
the @i(/mit) subtree and
a few other exceptions, Unix is open for inspection by anyone curious
enough to look.

The @p(/bin) directory contains the
binary (unreadable, excecutable machine language) versions of the
programs you absolutely can't bring up a Unix system without, such
as the @i(cat) and @i(rm) commands.  When you type the @i(cat) command,
you are actually executing the file @i(/bin/cat) in this directory.

The @p(/etc) directory contains all the administrative information
files necessary to run the system.  This includes the @p(/etc/passwd)
file that defines who has a username on the system.  It makes
for interesting browsing.

The @p(/mit) directory, as you already know, contains all user
files.  The @p(/projects) directory contains all the files for
Athena projects or courses.
Your host machine may not have a @p(/source) or @p(/src) directory.
It normally contains all the source code for the entire system.

Perhaps the most interesting directory is @p(/usr).  @i(/usr)
has traditionally
been where all users' files were kept.  (Athena uses @i(/mit) for this.)
Later, it also came to be the place where documentation, games,
and programs added at the local site were kept.  For example,
@p(/usr/ucb) has all the programs that the University of California
at Berkeley added to the original Unix to make Berkeley 4.2.
@p(/usr/athena) has all the programs, like Scribe and Emacs, that
Athena is adding to the Unix it got from Berkeley.   @p(/usr/doc)
contains documentation of general interest to users.  @i(/usr) is
worth quite a bit of browsing.

To get a detailed outline (somewhat out of date) of this entire
system tree, type:
@example[
host%  man hier
]

@newpage
@section(File Protection:  Who Can Read Your Files?)


You are the only person who can create, read, modify, delete,
and list the files under your own HOME directory.

This whole issue of who can see and do what to whose files is called
@b(file protection) or @b(mode).  Unix organizes file protection as follows:

The world of users is divided into three main categories:
@begin(description)
other@\All users, even users from other machines.  This is
often referred to as "the world," or "public".

@multiple[
group@\A group is a subset of users as defined in the file @p(/usr/group).
You can be a member of any number of different groups at the same time.
To see what groups you are in, type the command:  @p(groups).
Everyone in a particular course may be in one group, say 2.10.

All users are in a primary group called @b(mit).  Since everyone is in group
mit, it is for all practical purposes the same as world ("other").

There is currently no way for users to create new groups themselves.
]

user@\This is you.  This may sometimes be referred to as "owner."
@end(description)

A File is "owned" by:
@begin(description)
The user who created it.@\@b(The user who created a
file is the only person who can
change the protection on a file.) 
Only the superuser can change the owner of a file using the chown command.
It is why you never have someone give you a file; you always copy it
from them yourself.  Otherwise, you may find files under your directories
that you cannot delete because you don't own them.

@multiple[
One group.@\By default, a file copies its group ownership
from the directory under
which it was created.  Your HOME directory is owned by your primary
group, mit.  It is NOT owned by any other group you may belong to.
Therefore, unless you take active steps, all of your files will be owned
by group mit.

To see who the group owner of a file is, add the @p(-g) option to the
ls command:
@example[
host%  ls -lg filename
]
To see the group owner of a directory, say:
@example[
host%  ls -ldg dirname
]
You can change the group owner of a file with the @p(chgrp) command.
Only the user who owns the file can change the group it belongs to.
]
@end(description)

Each file, simple file or directory, has three kinds of access that can be
granted to it:  @b(read, write,) and @b(execute).  The interpretations of
these three access modes are slightly different for plain files and
directories.  They are as follows:@foot(Taken almost verbatim
from @i(Introducing the
Unix System) by McGilton and Morgan.)
@begin(description)
@multiple[
read@\A user who has read permission for a file can look at the contents of
that file.

A user who has read permission for a directory can find out
what files are in that directory.  If detailed information about
the files in the directory is required, the directory must also have execute
permission for that user.  Whether the user can see the contents of the files
in the directory depends on the read permissions for the files themselves.
]

@multiple[
write@\A user who was write permission for a file can change the contents
of that file.

A user who was write permission for a directory can change the contents
of the directory:  he/she can create new files under that directory,
and delete files stored in it.  Whether he/she can change the contents
of the files depends upon the write permission for the files themselves.

Write is the most powerful access permission.
]

@multiple[
execute@\A user who has execute permission for a file can use that filename
as a Unix system command, provided the directories above it also
have read permission turned on.

A user who has execute permission for a directory can change directory
to that directory and can copy files from that directory, providing the
user also has read permission for the directory.  The execute permission
is often called a "search" permission.
]
@end(description)

Thus, each file can grant three types of permission to three different
categories of users.  This vector of permission is called the file's
@b(mode).  The mode is expressed in two ways.  The first format is what 
shows up when you do an @i(ls -l) command.  A file with all permissions
turned on looks like:
@verbatim{
                    rwx rwx rwx
                    --- --- ---
                     |   |   |____ other (world) permission
                     |   |________ group permission
                     |____________ user permission
}
A missing permission is indicated by a "-".  Thus, a file with
user-only read, write, and execute permission would look like:
rwx------.

There is a second, numeric format in which to describe protection.
Here is a table of equivalences:@foot(Ibid.)
@newpage
@example{
                                user        group       other
                        
                               r w x        r w x       r w x
                               | | |        | | |       | | |
      400 ---------------------- | |        | | |       | | |
                                 | |        | | |       | | |
      200 ------------------------ |        | | |       | | |
                                   |        | | |       | | |
      100 --------------------------        | | |       | | |
                                            | | |       | | |
       40 ----------------------------------- | |       | | |
                                              | |       | | |
       20 ------------------------------------- |       | | |
                                                |       | | |
       10 ---------------------------------------       | | |
                                                        | | |
        4 ----------------------------------------------- | |
                                                          | |
        2 ------------------------------------------------- |
                                                            |
        1 ---------------------------------------------------
}

To translate the mode you require to a number, add up the numbers corresponding
to the individual permissions you want.  If you want the files to be
user read and write, group read, and world read, you would perform the
addition:
@verbatim{             
                     400   user read
                     200   user write
                      40   group read
                       4   world read
                    ----
                     644
}
Seriously.

A file with all permissions turned on (rwxrwxrwx) is referred to 
as a mode 777. rwx--x--x is 711.

@b(Notice that there is no way in this scheme to grant access to a file
to a particular user.)


@subsection(The Default Protection)

At Project Athena, the default protection for private files (under @i(/mit))
is rwx--x--x (711).  That is, only the user who created the files
can do anything with them.  The group and world x (execute) permission
does not give users in those categories any access to your files
unless they know the file's name
because they do not have permission to read the directories
they must pass through to get to the files.  It just makes it a
little easier for you to share one of your files should you
decide to later.

Project files (under @i(/projects)) are meant to be shared among members
of a group so their default is different:  rwxr-x--x  (751).


@subsection(Changing Protections)

You change the protection on a file with the @p(chmod) (for "change mode")
command.  The general form of the command is:
@display{
   chmod  @i(mode  filename)
}
@i(chmod) does not accept protections expressed in the the simple
rwxrwxrwx form, although it does allow a variant on that form.
Usually, people use the numeric (711, 644, etc.) form for expressing
modes.

We will now show you how to do some common protection changes.  You
should be able to figure out your own minor variations from these
examples.


@subsection(Make a File Readable by Everyone in a Group)

If you have a particular file that you want everyone in a group
to be able to read and execute:
@enumerate[
Change the file's group owner from the default mit to the name
of the group.  (Again, the group must be predefined in @i(/etc/group).)
@display{
           chgrp  @i(groupname  filename)
}

Now change the group protection on the file to allow group read and
execute.
@display{
           chmod 751 @i(filename)
}
@end(enumerate)

@subsection(Make a Directory Where All Members of a Group Can Read and Write)

Groups often want a directory that everybody can write on to place
the files they all want to share.  Athena projects would likely
do this under their @i(/projects/projectname)  administrative directory.
Here is how:
@begin(enumerate)
Make the directory.
@display{  
mkdir @i(dirname)
}

Change its group ownership to the correct group (must be
predefined in @i(/etc/group)).
@display{
chgrp @i(groupname dirname)
}

Change its protection to allow group read, write, and execute.
@display{
chmod  771  @i(dirname)
}
@end(enumerate)
Any files that you create under this directory will still have the
default protection of user read, write, execute  (rwx--x--x) only.
You and the other members of your group will have to individually reset the
protections to 711 for each file that you place here.  Otherwise,
people in your group will be in the strange position of being able
to delete files they cannot even read!  (w on the directory, but
no r on the file itself.)

Athena courses may well wish to make directories that allow group
read and execute only (751).


@subsection(Make a Public Directory)

Many people will want to create a public directory where they will
place things that they wish to offer for the public benefit
of the community.
@begin(enumerate)
Make the directory.  Calling it @i(public) would be intuitive.
@display{
host% mkdir public
}

Change its protection to world read and execute.  (World
write is inviting trouble.)
@display{
host% chmod 755 public
}
@end(enumerate)
Again, you will have to manually reset the protection of each file you
place under your public directory to 755 because it will be created
with the more restrictive 711 default.


@subsection(Open Your Files to All:  An Interesting Issue)

The traditional default file protection on Unix systems is
rwxr-xr-x.  In addition to the file's owner having full control
of his/her own files, all other users are permitted
to read a user's directories and files unless that user takes
explicit action to close off access.  Anyone can look at and
copy anybody else's files.

Project Athena started creating user accounts with this traditional
rwxr-xr-x (755) protection.  The MIT Committee on Privacy that is charged
with safeguarding the privacy of MIT students, faculty, and
staff reviewed this default protection and decided that it should
be changed to rwx--x--x (711, owner access only).  The
default protection was changed on September 6, 1984.

The reasoning is a combination of the belief that 1) the
protection scheme of the traditional Unix would not scale up to
the eventual Athena community size of 10,000+; 2) that most people
do not expect their files to be public, do not investigate the
question, and are quite surprised and upset when they find out
that this is the default; and 3) that the Unix file protection
mechanism is too complicated to grasp quickly when one is new to a
system and not interested anyway and therefore the burden upon the
novice to figure out how to make files private is unreasonably
great.

The feeling is very strong among Unix programmers that the
traditional relaxed, shareing, open attitude toward file protection
is a major factor contributing to Unix's success as an operating
system.

If you want to profess the Unix "live free or die" philosophy
and make your files publically readable, here's how:
@begin(enumerate)
Edit your .login file.  Change the line reading
    "umask 66" to "umask 22"  (Umask uses yet a different
    numbering scheme, the octal ones complement of the other
    numbering scheme.)  Umask 22 is rwxr-xr-x (755).  Your umask
    controls the default file protection for you create.

You must change the protection on your HOME directory:
@display{
chmod 755  ~/
}

If you wish you can then change the protection on your
existing files to 755 with the @i(chmod) command.  @i(chmod)
    does not have a -r recursive option, but you can use the *
wildcard character.

If you do wish to have private files, the convention is to
create a subdirectory and keep the files there:
@display{
mkdir  private
chmod 711 private
}
@end(enumerate)
    You do not have to individually change the protection
    to private on the files within the directory as you have to
    individually "liberalize" the protection of files in a
    public directory.  This is because the private mode on the directory
    effectively locks the door to anything below it.


@subsection(Caveat Emptor:  A Final Warning)

A conversation overheard:
@begin(description)
Systems programmer:@\@i["I came in on Saturday because I had to change some
                       things and I discovered that G---- had
                       changed the root password.  Changed the root
                       password without telling anyone what the
                       new one is!  Well, I had to get my stuff done,
                       so I dinked around a bit and you know how
                       long it took me to break in?  Eleven minutes."]

Manager:@\@i["You're slipping."]
@end(description)

The expertise that let the programmer above figure out how to log in
as the root user--who can do anything on a Unix system--in under
fifteen minutes without knowing the password is fairly common
around MIT.  Unix is not a secure operating system.  Although
file protection is set up so that only you can manipulate your
files, this is really not anymore effective against the determined
intruder than the lock on your house door is against a burglar.

The best that Athena can offer to keep data private is the @p(crypt)
command.  This allows you to encrypt a file using a key you specify
so that even if someone does read the file, they will see only
gibberish.  This, however, doesn't protect against malicious
deletion or overwritting.

The final word must be that if you have data that MUST be
private or that you cannot stand to lose, don't keep it
on Athena.


@newpage
@section(Exploring Your Environment)

The purpose of this section is to introduce you to some of the
features of your new Unix environment.  Rather than explaining
in detail what they are and how to manipulate them, the point
is to let you know that they exist and can be manipulated
at a later time if you want to invest the effort to learn how
to do it.


@subsection(The Files that Come with Your Username)

You may have noticed that your new username already has a number
of files in its HOME directory.  To get the complete list, since
most of them are "dot" files that don't normally
show up, add the @i(-a) option to the @i(ls) command.  You will see
something like:
@example[
host% ls -a
.         .emacs_keys        .logout      .tiprc
..        .emacs_vars        .mailrc      Mail
.cshrc    .login             .mh_profile  welcome
]
What are these files?
@begin(description)
@b(. and ..)@\These are the files that implement
the synonyms . and .. for "working
directory" and "the directory above me."  You can ignore them.

Mail@\This is the directory where your Mail is kept once you've @i(inc)'d
(incorporated) it.  See the free Athena document, @i(Essential Mail)
for an explanation.

.cshrc@\This is an important file.  It is a file full of commands to the
C shell (csh).  This file is executed every time you start up a 
csh.  The most obvious time you start a csh is when you log in.
Here are a few highlights:
@begin(description)
set history=40 savhist=50@\ Set commands are csh
@(built-in) commands.  They give @i(csh)
 variables values.  The C shell has a so-called @b(history)
 mechanism.  This means it keeps the commands you enter
 during a session.  You can use the history mechanism to
 re-execute commands you've already entered or to edit long
 commands you made mistakes in.  This line tells the history mechanism to
 keep the last 40 commands you entered, and to keep the last
 50 commands you've entered during your previous login sessions
 in a file called @i(.history) in your HOME directory.

alias mail Mail
alias back 'set back=$old, set old=$cwd; cd $ back; unset back; dirs'@\The
csh @b(alias) mechanism lets you invent and name new commands out of
old ones.  The first alias is a simple one, it changes the definition
of the all-lowercase @i(mail) command to point to a newer, better
program.  (Neither of which Athena supports.)  The second alias
is defining a new command, @i(back), that remembers the last directory
you were in and changes you back there.  As another example of a
useful alias, if you like the @i(-F) option to the @i(ls) command that
shows you what type of file each file is, you could redefine
the @i(ls) command in your @i(.cshrc) file like
this:  alias  ls  ls -F
Now @i(ls) will always show you the file types.  alias logout bye
would make "bye" a synonym for logout.

.emacs_keys
.emacs_vars@\Emacs is the Athena-supported editor.   Emacs works by "binding"
keystrokes to editing commands, like binding CTRL-N to 
"go down one line."  You can customize these bindings to suit
yourself by defining new bindings in this @i(.emacs_keys) file.
Emacs also has variables that control things such as "should
I automatically wrap long lines or not?"  You can define
different default values for these variables in this @i(.emacs_vars)
file.  Notice that both files are empty when you get them.
@end(description)

.login@\This is the most important file here.  It is a file full of
@i(csh) and Unix commands that is executed everytime you login.
It does the most to establish the Athena character of your
environment.  Here's what the lines are doing:
@begin(description)
#@\comment character

stty dec@\This line defines DELETE as the erase character, CTRL-C
as the quit character, and several other less important key strokes.
If you preferred different keystrokes for these functions, you can
change this @i(stty) line to somethig else.  See @i(man stty).

@multiple[
set path=(. $HOME/Bin /usr/athena /usr/new /usr/new/mh /usr/ucb
           /bin /usr/bin /usr/local /usr/games /usr/hosts)@\This
sets the csh @b(path) variable.  What's that?  Remember that we
said that a Unix command was nothing more than
the name of file with a program in it?  What happens when you type
a "command", say @i(ls), is that Unix takes this path variable--which
is nothing more than a list of directories--and looks in each
one until it finds a file called @i(ls) and then tries to execute it.
(It must have x "on".)  For @i(ls), it would look first in your
current directory (.), then in a @i(Bin) directory in your HOME
directory, then in the directory where Athena is keeping its
additions to Unix (like Scribe and Emacs), then in the next
directory, and so on until it found a file called @i(ls).
(It would have found @i(ls) in @i(/usr/ucb).)  If there's more than
one @i(ls) (there is), it executes the first it finds.  This is the
way all "commands" work.

The search path variable is an extremely important, extremely flexible
tool.  It literally defines what commands you "know about."
If you were working on a project or taking a class where
important programs you were asked to execute repeatedly were being kept
in a central directory, you could add that directory to your path variable
search list and treat all the program names just like commands.
]

setenv ...@\@p(setenv) commands
are similar to set commands.  They establish values for
csh environment variables.  @i(setenv VISUAL) and @i(setenv EDITOR) are
part of what causes the Emacs editor to be called when you're
composing mail instead of any other editor on the system.  @i(setenv
PRINTER laser) is what makes the laser printer your default instead of the line
printer.  To see what environment variables there are and what they
are set to, enter:  @i(printenv)

set ignoreeof@\On Unix systems,
CTRL-D traditionally works just like the logout
command.  This can really surprise people and so Athena disabled
it as a logout equivalent with @i(set ignoreeof).

set noglob ...@\This sets your terminal
type correctly or causes you to be asked
for a terminal type if you are dialing in.  Don't change it unless
you understand exactly what you are doing.

/usr/games/fortune@\This is what causes
the "fortune cookie" to appear at login.
If you are getting tired of the quips, you can delete this line
and they'll go away.

msgs -q@\This checks to see if there are new system messages that you
haven't read before.  Without it, you would never see that
"There are system messages" line you sometimes get at login.

umask 66@\This is what establishes the default protection on all of
your files as rwx--x--x.  If you want to change the default,
you would change the number on this line.  See the previous section on
"File Protection."

If you edit your .login file, the changes will not take effect until
you either logout and login again, or you type this command:
@end(description)
@display[
host% source ~/.login
]


.logout@\like @i(.login),
but executed at logout.  Athena's default contains only
a command to clear the screen.

.mh_profile@\sets certain standard
values used by the @b(mh) mail system, including
what editor to use and what protection to give your mail files.
@end(description)

The rest of the files are not very important.  Various system utilities
like @i(msgs) and @i(notes) may create files like this in your HOME directory.
Most will have the suffix "rc" (short for "run command file").  The
utilities use these files to save state and variable information.

If your Unix username is a course or
project username like 6.032 or 2.10, then you
will have some additional directories.  See the README file that
comes in your HOME directory for more information.


@subsection(Your Neighbors:  Who's On?)

Unix is an intensely social system.  Unix users spend a great deal
of their logged-in time exchanging mail with each other, participating
in the public discussion forums, and talking with each other.
Here are some of the programs that assist this socialization:
@begin(description)

mh@\The Athena electronic mail system.  @b(mh) is not a command, but an
assemblage of system-level commands that together make up
a mail utility.  To learn about mh, get the free Athena document
@i(Essential Mail).

/etc/passwd@\This is the raw accounting file that says who has accounts on
your machine.  List it out with the @i(more) command.  See
@i(man 5 passwd) for an explanation of what you're looking at.

users
who
w@\These commands tell you, with progressively greater detail, who
is logged on to the system at the moment.  See their respective
man pages.

finger@\The @p(finger) command has two forms.  As just @i(finger), it tells you
who is logged in.  When specified as:
@example[
finger string
]
where @i(string) is a username or a part of a person's name, @i(finger)
searches through @i(/etc/passwd) to find who it has on the system that
matches string, then prints out what information it has about them.
See @i(man finger).

.plan@\If you create a file called @p(.plan) under your HOME directory
that contains whatever personal data you care to tell the world
about yourself, then when someone fingers you, this @i(.plan)
file will be displayed.  See @i(man finger).

chfn@\This program lets you add fundamental information (office, phone
number) about yourself to the @i(/etc/passwd) file.  This information
will be printed when somebody fingers you.  See @i(man chfn) for
details.

talk@\This is a fun program.  If another user is logged in, you can converse
with them without the delays of electronic mail.  The spontaneity
of the exchange is more like a phone call than a letter.  See @i(man talk).

notes
msgs@\Both of these are public discussion forum systems.  They can be
a great source of information and recreation, and also an infinite
time sink.  @i(notes) is much more advanced than @i(msgs), but as of this
writing it was not clear that it would be available for the Fall '84
semester.  See @i(man msgs) and @i(man notes) (if available).
@end(description)

@subsection(What's the System Doing?  ps)

The @p(ps) ("process status") command prints information about processing
running on the system.  A @b(process) is almost anything; any command
entered, anybody logged in, any jobs the system (root) is running.

The @i(ps) command has many options.  Here are two common versions:
@display{
  print out all the information about my processes:   ps -ux
  print out all the information about all processes on the host system:  ps -aux
}

@newpage
@section(To Kill a Session)

The one thing you don't want to do is leave yourself logged into
Athena.  You may have accidentally dropped a dial-in line, or
gotten hopelessly stuck inside some program that simply won't
let you out and turned off the terminal and walked off hoping it would
somehow go away; but you are really still logged in and vulnerable.
The next person who dials in or turns on that terminal will
be logged in as you.

The final recourse is to start a new terminal session and kill
off your old one.  You will rarely lose anything.  The Emacs
editor, if it is interrupted, will save the state of the file it is
editing in a file called @i(#emacs1).

To kill an old session, login on another terminal.  (If you
are dialing in, just dial-in again.)
  
@begin(enumerate)
@multiple[
Once logged in, give this command:
@example{
host% users
dssaxon nbsina you you pegray dkfritz glwilson
}
    This verifies that you are, indeed, logged in twice. 
]

@multiple[
If you are logged in twice, then give this command:
@verbatim{
host% ps -ux
USER       PID %CPU %MEM   SZ  RSS TT STAT  TIME COMMAND
you      29001 81.3  3.0  157   94 ?  R     0:00 ps -ux
you      28961  6.0  1.7  121   52 co I     0:00 -csh (csh)
you      28949  0.5  1.7  121   52 co S     0:00 -csh (csh)
}
    These are all the processes that belong to your login id.
    Find the one with the lowest PID ("process id").  It is
    @i(probably) the oldest, and hence the one you want to do away with.
    It should also have "-csh (csh)" under the "COMMAND" column,
    indicating it is a login shell.  There should be two such "-csh"
    processes, otherwise your old process is probably already gone.
]

@multiple[
Issue this command:
@example{
       kill -9 process-id
}
    Replace "process-id" with the PID of the oldest process you
    found above. (In this example it would be 28949.)
]

@multiple[
Verify with more @i(users) and @i(ps) commands.  You have now
    most probably killed off your orphan session. 

 If, instead, you
    suddenly found yourself logged off, then you have killed
    your current login process, not your old one.  Sometimes the
    lowest PID is @i(not) the oldest process.  This is rare, but
    it happens.  You will have to repeat the entire procedure,
    only now kill the other -csh process.
]
@end(enumerate)

@newpage
@section(Dealing with Other Machines)
Your host system is part of a network of Athena machines connected
together.  The @i(Athena Terminal Cluster Map) shows the hosts and
their locations.  This map is available in 8 1/2 x 11 card form,
and should also be posted in each cluster.

You will often need to deal with these other machines, perhaps because
you're sending mail to a friend who is on a different host, or because
you need to copy a file that is stored on another machine.

Unix refers to other machines in two main ways.  The "r commands"
are versions of simple Unix commands that have been rewritten to
work on a @b(remote) host.  Commands that refer to usernames
such as @i(finger), @i(talk), and mail commands use the @B(user@@host)
syntax.

@subsection(To Login to a Different Host:  rlogin)

To @p(rlogin) to a host you must have an account on that other host.
Most people have accounts on only one Athena host, so you will
probably not be able to login to other machines.  Let's say that
you are logged into hera and want to go over to priam to look
as some files you were working on there.  The process would
look like this:
@display{
hera% rlogin priam
PASSWORD:

Last login:  Fri Aug 30 14:07:04 on tty04
Athena Unix #.55  Saturday Sep 1  17:28:18 EST 1984

Welcome to Project Athena

priam%
          .
          .    (do your work on priam)
          .
priam% logout
Connection closed.
hera%
}
See @i(man rlogin) for more information.

@subsection(List the Status of Machines on Network:  ruptime)
The @p(ruptime) command lists status information about all the machines
on the network.  Some clusters may not show up in the list for
security reasons.  It looks like this:
@example{
host% ruptime
mit-bitsy     up    12:04,     0 users,  load 0.44, 0.41, 0.40
mit-castor    up    17:47,     0 users,  load 0.12, 0.09, 0.08
mit-ciaran    up 13+15:45,     0 users,  load 0.46, 0.45, 0.45
mit-hector    up  1+11:07,     0 users,  load 0.00, 0.03, 0.03
mit-helen     up    15:31,     0 users,  load 1.29, 0.81, 0.62
mit-heracles  up  6+06:25,     0 users,  load 0.08, 0.08, 0.09
mit-jason     up  2+20:01,     0 users,  load 0.00, 0.03, 0.04
host%
}

@subsection(Who's On?: rwho)
The @p(rwho) command lists everybody that is logged in on hosts
all over the network.  Again, some clusters may not be listed.

@subsection(Copying Files Between Hosts:  rcp)

You can copy files between hosts even though you do not have an
account on the remote host.  The remote host will log you in as
a "dummy" user named @i(default), attempt the copy, then log you
out again.  From your perspective, it looks just like a slightly
slow @i(cp) (copy) command.  The file(s) you are trying to
copy must be readable by the world.  The format of the @b(rcp)
("remote copy") command
is:
@display{
rcp  @i(remotehost:filename  tofile)
}
where @i(remotehost) is the name of the other machine.
@display{
hera%  rcp paris:~mycourse/assignments/week2  week2
}
copies a file called @i(week2) out of the user mycourse's directories
on the paris system into a file called @i(week2) on my current
system, hera.

@subsection(Run a Command on a Remote Host:  rsh)
You can run single commands on a remote host with the @p(rsh) command.
The command cannot be "interactive," e.g., @i(cat) will work,
but @i(more) won't.  The format is:
@display{
host%  rsh  @i(remotehost  command)
}
@subsection(@i(Finger) and @i(Talk))
When you want to speak about a user on a different host, you refer
to them as:
@display{
username@@host
}
Thus, if you're logged into host aphrodite and you
want to @i(talk) to user dkfritz who is logged in
on host prak, you would say:
@display{
aphrodite% talk dkfritz@prak
}