There are a number of additional keys. Depending upon the type of terminal or workstation you are using, there may be "special function" keys above your keyboard, with labels like "F2", special keys to the left with labels like "L1" or "STOP", and special keys to the right with various special labels. More about them later.
The most important additional key is the Control key. This is located to the left of the normal letters, and is labelled "Control" or "Ctrl". It acts like a shift key, in that you hold it down and then type something else. For example, if you hold down Control and hit a C, that's called Control-C. When characters are printed, an uparrow is normally used, so Control-C would be printed as ^C. In different documentation, you'll see it called ^C, Control-C, Ctrl-C, or even C-c. Control-C is an important character to know about, but you can use it to interrupt programs. Suppose you are testing a program and it gets into an infinite loop. If you type ^C, the program will be killed. (This assumes that the program is a fairly simple one, like most of those you will write for assignments. It is possible for programs to block ^C, or to redirect their control to someplace unexpected. It also assumes that you type ^C in the window where the program is running.)
When you're typing a command, nothing will happen until you hit the "return" key. That gives you a chance to fix typos and look carefully at the command before you hit "return".
Unix is "case sensitive". That is, there's a difference between upper and lower case characters. The command "ls" will list all files in your directory. If you try to type it as "LS", you'll get an error message. Some commands use upper-case letters in the name, e.g. "Mosaic". In this case, you must use the upper-case letter exactly as shown. More commonly, some command options use upper case. For example, the "ls" command has an option called "-R". It must be typed in upper case. If a sentence begins with a command name, we'll violate the rules of English, and give you the command name as it really is: "ls" is the most common Unix command. However a lot of manuals will stick with English rules: "Ls" is the most common Unix command. The command is still "ls". It won't work if you type it as "Ls".
The same thing is true with file names. If you use both upper and lower case letters in a file name, you'll always have to type it that way. Some people use VeRy OdD CaPiTaLiZaTiOn in their file names. That's fine, but they'll have to remember to type the names that way all the time.
The most common key for fixing typos is "delete". This key deletes
the most recent character you typed, and in most cases removes it from
the screen. Unfortunately this key is the most complex, because there
is confusion about which key and ASCII code should be used.
Our computers are configured to use the ASCII DEL character (decimal 127) to delete. Most keyboards now are set up with a key called "Backspace", which generates a different code (ASCII BS, which is the same as ^H, decimal 8). Some of our software will recognize either key, but not all of it. Thus you will either want to adjust our software to accept a backspace, or make sure that your keyboard generates a delete. Here's some advice, depending upon the type of keyboard you use:
xmodmap -e "keysym BackSpace = Delete"
If for some reason you prefer using a backspace rather than a delete, you'll need to tell Unix to treat the backspace character as delete. To do this, put the following command into the file .cshrc in your home directory:
stty erase "^h"The disadvantage of this is that the editor emacs does not work well with this setting. So we only recommend this if you use a different editor (e.g. vi).
Summary of special characters
^C and delete are the most important special characters. Here's a
summary of all the ones you'll want to use as a beginner:
There is one more character that we'll talk about later: ^Z. You should not use this unless you know about job control. It can get you into states that you won't know about to get out of.
^D is the end of file character. It's not used very often. However sometimes a program will open the terminal as if it were a file. In this case, what you type will become input to the program. There needs to be some way to tell the program when you're finished giving it input. ^D is it. (It corresponds to ^Z in MS/DOS.)
Setting things up
In order to help you to tell Unix about yourself, we have
created a command called "newuser". The first time you log in,
this will be run for you.
It does 3 things:
Terminal type:when you log in. It's looking for a terminal model name. These days the name "vt100" will work most of the time. (Don't type the quotes.)
This program creates some files for you, e.g. .cshrc and .login.
You may want to adjust these files yourself. For help in doing so,
see the handout "Tailoring Your Setup: .cshrc".
Files and Commands that Deal with Files
Most programs and data you use will be stored in "files". A file is
an area of storage to which you assign a name. You can put anything
you want into a file: a program, a set of data, or a paper you are
writing. You usually decide what you want to call a file when you
first create it and start putting data into it. However you can
change the name later if you want to (with "mv").
Each file has a name. Normally the person who creates the file chooses the name. Names are from 1 to 255 characters, normally letters, digits, and some special characters such as "." and "_". There is a naming convention that you will do well to follow. Although it is not strictly necessary, it will help the system programs to figure out what you are doing. Under this convention, file names have at most one "." in them. The part of the name after the "." is called the "extension". It is used to describe what sort of thing is in the file. For example, "prog.p" is probably a Pascal source program, since ".p" is the extension normally used for Pascal. Similarly "prog.o" is probably a relocatable binary file, produced by compiling prog.p. Normally executable programs are given names without dots at all.
A collection of files belonging to a particular user, is called a "directory". The login procedure puts you in your own directory. When you refer to file names with no special qualification, you will get a file by that name in your directory. In order to refer to a file in another directory, you must specify the directory name in front of the file name. Directory names normally have "/"'s around them. For example, the file name "project.p" would be a file in your own directory. "/bin/rm" is a file in the directory "/bin". "/usr/ucb/mail" is a file in the directory "/usr/ucb". Normally you will be using files only in your own directory, except for systems programs that you run.
Most commands let you specify more than one file at a time. For example, to remove files "x" and "y", you could say "rm x y". ("rm" is the "remove" command.) There is also a shorthand that makes it easier for you to specify several files. The characters "*" and "?" in a filename act as "wildcards". A filename that includes one of them is actually a pattern. It expands to include a list of all files that match the pattern. For example, "rm *.s" would remove all files whose name ends in ".s". That's because * matches any character or sequence of characters. There can be more than one * in a name. E.g. "*pro*" will match all files with "pro" somewhere in their name. Since * will match the null string, this includes names that begin or end with "pro". The character "?" is used less often. It match any one character. So "rm ?.s" matches only files whose names have exactly 3 characters, the last of which are ".s"
In Unix, everything on the system is considered to be a file. The things that aren't really files are typically allocated pseudo-filenames in the directory "/dev". Thus your terminal is "/dev/tty", and the tape drive "/dev/mt0".
Common Commands Dealing with Files
Here are the most common commands that deal with files. Note that
the following list does not show how to create or edit a file. This
is done with an editor, which is the subject of a separate section.
If you just type "ls", it will list all of the files in your directory.
The first option you have is to give it a filename to look for. "ls *.p" will show you all files than end in ".p". "ls /bin/a*" will show you all files starting with "a" in directory /bin.
So far all you will have seen are lists of filenames. It is also possible to ask "ls" to give you more information about a file. That's where the options come in. Options give extra details about how you want the command to be executed. Normally the options come right after the name of the command, with a hyphen in front of it. For example, "ls -l" will give you a "long-form" directory listing. For each file, this will show its size, creation date, owner, etc. If you wanted to see this information for all files ending in ".p", you would put the option before the file names, i.e. "ls -l *.p". If you want to specify more than one option, put all of the letters after the hyphen, e.g. "ls -lt" will give you a long-form listing, sorted by creation time. This is useful for reviewing the files you have created recently, since those will show up first. Here are the most common options for ls:
In order to print a file on a printer, you need to know two things:
of the printer, and what kind of file you're printing.
There are so many printers that we're not going
to list them here. In general, you should find a printer near
where you're working, and ask the staff what its name is.
However you can only print if the printer is attached to the
network and will accept printouts from Unix. The RUCS public
facilities all have such printers. So do many departments.
On our Suns, the command "printers" will list printers that
are valid on your machine.
Now for file type: Most files you deal with will be plain text files. These are files that you create or edit in a text editor such as emacs. You can print files like this without any special precautions. However when your file comes out of a program, you need to be a bit careful. If you want to see whether a file is printable, look at it using "more" or "emacs". If it looks normal in more, you can print it. You can also print Postscript files. They start with a line like this:
Many files can't be printed on a printer at all. For example, the output of a compiler is a binary executable file. It makes no sense to print it. It would come out as junk. In other cases, the file can be printed, but it requires a special program. The most common examples are the output of TeX or LaTeX, and graphics files such as .GIF files or files produced by the Island tools.
In these cases, you need a program that understands the file and can convert it into printable output. At Rutgers, you normally want the printable output in a format called "Postscript". Postscript is a special language that can be used to describe graphics, special effects such as boldface or italics, etc. There are "filters" to convert just about everything conceivable into Postscript format.
It used to be that we tried to do file conversion automatically as part of the print program. This has turned out to be a bad idea. If you look at the printer documentation, you'll find that options to do this are still around. However they don't always work well, and we will probably be removing some of them in the future. Now if you want to print something that needs conversion, we recommend that you run the converter program yourself. In many cases, the converter program can print the file automatically. The most command case is TeX and LaTeX (languages used for document processing). They produce output in a special format called DVI. We use a converter called "dvips" to convert this into Postscript.
Once you know the printer name, and any conversions needed, you can issue the print command. If the file is plain text or it's already been converted to Postscript, you can issue a simple print command, e.g.
lpr -P printer filename
If your file needs conversion, there are two possibilities. Some of the converter programs will issue the print command for you. dvips is an example of this. So to print a DVI file you could use the command
dvips -P printer filenameIn other cases, the converter is a "filter". This means that it puts the converted output to "standard out". Filters are designed to be stuck together with the print command using "|" (the "pipe" character). For example, "ras2ps" is a converter that takes a Sun rasterfile (which is produced by certain programs that make a copy of your screen) and produces Postscript on standard output. So to print a raster file, you would use
ras2ps filename | lp -d printer
The man page should tell you whether the program sends the file to the printer itself, puts the output into a file, or puts it to standard output. If the program sends the file to the printer itself, that's all you need. If it puts the output into a file, then you'll need to use lp or lpr to print the file. If it puts the output to standard output, then you'll need to use "| lp" or "| lpr" after the program.
lp and lpr have many options. You should look at the man page to see what they are.
In order to prevent one user from using hogging all the space, we have
disk quotas on many of our systems. You are not allowed to use more
space on a given file system than your. To find out what your quota is, type the command
"quota -v". (Quota with no argument only prints something if you
are over quota. It's suitable for use in .login.)
Here is an example of what you will see:
Disk quotas for hedrick (uid 103): Filesystem usage quota limit timeleft files quota limit /ug/u1 69 1 3500 7.0 days 0 0 0 /ug/u2 0 1000 5000 0 0 0
In order to keep people honest, we have to make sure that you don't stay over your quota too much. The idea is that you are supposed to get your usage down to the quota when you log out. In login, this is checked. If you are over quota when you log in, you will get a warning message. It will say something like "Over disk quota on /ug/u1, remove 1K within 7.0 days". If you use the quota command, you will now see 7.0 days in the timeleft column. If you do not get within quota by that time, the system will conclude that you are a hopeless pig, and prevent you from creating any more files until you fix the problem. At that point, you will have to delete enough files to bring your usage down to the quota. You will then have to log out and log in again.
There is a possible problem with quotas. Current usage refers to all files that you own. That is, all files that show your name in the owner column when you do "ls -l". You own every file that you created. You also own your own mail file. So if someone sends you a lot of mail, this can put you over your quota. Also, if you copy a file into someone else's directory, you still own it, and it is still counted against your quota. If you want to give someone else a file, you should let them copy it. Note that current usage also counts files that have not yet been closed. If a program is still running, it may be using disk space that does not show in an "ls -l" command.
************ NOTE ***************
The following sections give more details about files and about using commands. On your first reading, you may want to skip to Using the Documentation and Help Facilities.
More about Directories and "cd"
Every user has a "home directory". This is a directory that is
associated with the user name. Normally it has the same name as the
user name, although there may be another directory or two above it.
For example, the user hedrick might have a home directory
Most users end up with so many files that it is hard to keep track of them all. They end up wanting to create more directories. For example, they may have separate directories for each course they are working on. Normally these additional directories are put within the user's home directory. Thus if hedrick is taking courses 431 and 435, he might create directories /u2/hedrick/cs431 and /u2/hedrick/cs435.
To create a directory, use the command "mkdir". For example, "mkdir /u2/hedrick/cs435". As with file names, you often will not bother to type out the entire directory name. If you are currently in /u2/hedrick, it would be easier to type just "mkdir cs435".
At any moment you are always in some directory. In various documentation this is called your "current directory" or your "working directory". (To my embarrassment, some of our documentation calls it your "connected directory". This terminology is from TOPS-20, our previous operating system. It does not apply to Unix.) If you mention a file name but don't specify a directory, it refers to this current directory. That is, if you in "/u2/hedrick", then the filename "prog.p" means "/u2/hedrick/prog.p". You change current directories using the command "cd". The full form would involve naming the whole directory, e.g. "cd /u2/hedrick/cs431". As usual, you will often not bother to do this. For example, if you were already in /u2/hedrick, then "cd cs431" would change your directory to "/u2/hedrick/cs431".
The "pwd" command prints the current directory, in case you have forgotten. (pwd stands for Print Working Directory.)
Be sure you know where you are before you do mkdir. Otherwise you can have unintended effects. For example, suppose you were in /u2/hedrick/cs435 and you did "mkdir cs431". You would end up with /u2/hedrick/cs435/cs431. That's probably not what you intended. Of course if you want to be safe, you can use the full form: "mkdir /u2/hedrick/cs431".
The abbreviation ".." means the directory above the current one. This can be handy for getting back up to your home directory. If you were in /u2/hedrick/cs431, then "cd .." would get you to /u2/hedrick. You can use .. with other things, e.g. "cd ../cs435" would take you up to /u2/hedrick and then back down to /u2/hedrick/cs435.
The abbreviation "." means the current directory. This isn't normally needed, since this is the default. However a few commands require you to specify a directory names, and "." can be useful then.
More About Specifying Other Files Belonging to Other Users
It would be nice if the way to access Smith's files was always to give
a file name starting with /smith. Unfortunately, things are not so
pleasant. For efficiency reasons, Unix system managers do not
generally put everything on the same file system. Thus you are likely
to find two more levels of directory than you would expect. Typically
users' directories have names like /ug/u1/smith and /grad/u2/jones.
The top level directories represent separate file systems. These may
be separate disk drives, or at least separate at least separate
physical parts of the same disk drive. On most large Unix systems,
there are at least 3 file systems: /, /usr, and at least one more file
system for user directories. None of this matters particularly to
you, except that it makes it harder for you to figure out where to
look for a given user's files. For this reason, there is a special
syntax: ~user. ~jones means the home directory for the user named
"jones". It expands to /ug/u1/jones, /ug/u2/jones, or whereever jones may
happen to be. So to refer to the file prog.p on hedrick's directory,
you would type "~hedrick/prog.p".
Some Useful Details: Ownership and Privacy
Unix allows you to control who can access your files. If you don't do
anything special, anyone on the system can read or execute any of your
files. However you can do things to exercize more control over file
You can control access at two levels: the individual file, or the whole directory. In order to get to one of your files, someone else must have the authorization to look in your directory. If he can't look in your directory, then nothing else matters. Once he can look into your directory, then each individual file has its own code to say what he can do. So you can lock out users from individual files by changing the file permissions. Or you can lock them out from the whole directory by changing the directory's permissions. (In some of our documentation, the term "protection" is used rather than "permission". The proper Unix term is "permission.")
Some aspects of file protection depend upon "groups". A group is a set of users. It has a group id, which is a number, and a group name. The groups are set up by the system administrator. Normally they represent classes and research projects. So there is a group "cs431-a", which contains all students in Computer Science 431, section A. There is also a group "vlsi-design", which contains all users in the VLSI design project. One of the things you can do is to say that everyone in a certain group can access your files. If you find that you need a group that is not already defined, you should contact your system administrator, by sending email to the pseudo-user "help". The groups are listed in the file /etc/group.
In order to provide you with maximum flexibility, Unix allows each file to have three attributes that affect who can access it.
The commands "chown", "chgrp", and "chmod" are used to change the owner, group, and mode of a file. (However only a superuser can use chown.)
Although the mode is actually a number, you normally look at it by using the "ls -l" command. It displays the mode in a form that looks like the first line below.
-rwxr-x--- xxx owner xxx group xxx others r read w write x execute (search for directory)There are three groups of three letters. The first group applies to the owner, the second to the group, and the third to all others. The letters mean read, write, and execute. So the code "-rwxr-x---" means that the owner can do anything; others in his group can read or execute the program, but not change it; and others can't do anything with it at all.
As mentioned above, in order to be able to access one of your files, a user must have the appropriate permission in the file mode, but he must also have access to the directory itself. The protection bits have a slightly different meaning for directories. Read allows the user to read the directory as a file. In practice, this controls whether he can do wildcard operations such as listing all the files in the directory. Write controls whether he can do operations that involve changing the directory, i.e. create or remove files. Execute controls whether he can open existing files. If execute is missing, the user cannot open any file in the directory, even if the files themselves have permissions that would allow him to do so. If the execute bit is on, then the user can do operations on individual files according to their permissions.
Typically directories are set up to have modes "-rwxr-xr-x", which means that the owner can do anything, and everyone else can access files according to their individual modes. The "r-x" allows other users to look into the directory and at the files in the directory. Because "w" is missing, the other users can't create new files in the directory. If you wanted to have a totally private directory, you would use "-rwx------". In this case, no one else could look at anything in it. If you wanted members of your group to be able to create files in your directory, you might use "-rwxrwxr-x".
In Unix, file names and files are conceptually separate. It is perfectly possible to have two different names for the same file. In that case, there are simply two different directory entries that point to the same file. In order to avoid confusion, the term "i-node" is used to refer to the file as a physical entity. So we would say that a file with two names is an "i-node" having two directory entries that point to it. We refer to the connection between a directory entry and an i-node as a "link".
The "ln" command can be used to link a new name to an i-node. The format is "ln old-name new-name". Note that it is perfectly possible for the two names to be in different directories. So you and your friend could share a file by using the "ln" command to create a second link to it. Note that the ownership information is part of the i-node. So the one that created the file initially would still own it. But it would appear identically in both of your directories. The file will continue to exist until both of you delete it. That is, the "rm" command really only removes the link from a name to an i-node. The i-node goes away when there are no more links to it.
There is an additional kind of link, a "symbolic link". This is a link from one name to another name, instead of from a name directly to an i-node. Suppose you wanted to make "myprog" in your directory point to your friend's version: "~smith/myprog". You could of course say "ln ~smith/myprog myprog". However if your friend ever deleted myprog and created a new one, your link would continue to point to the same i-node, namely the old file. So you might prefer to use a symbolic link: "ln -s ~smith/myprog myprog". This says that myprog in your directory is linked to ~smith/myprog, whatever it may happen to be at the moment. That is, instead of being linked to a particular physical file, it is linked to the name. Most people do not use symbolic links. A normal link (technically called a "hard link") will normally do the right thing. There are special provisions in the editors so that when you edit a file that has more than one link, all of the links are maintained. But there are some situations where a symbolic link may make sense.
Unless you are a super-user, you can't create a hard link between two directories. So one of the more common uses of symbolic links is for directories. Suppose you have a friend who is working with you on files in the directory /ug/u2/smith/cs431/source. You may not want to type all of that every time you want to access one of his files. So you might do "ln -s /ug/u2/smith/cs431/source smith". Then if you refer to "smith/foo" you will really get "/u2/smith/cs431/source/foo".
The commands that you type to the system are processed by a program
called the "shell". The shell reads your command, and then calls a
program to execute it. The shell can't do very much on its own. But
it is an expert at coordinating other programs. There are several
different shells used on Unix. They all understand the same basic
commands, but they have different additional features. The shell that
we use at Rutgers is an extended version of the C Shell, called tcsh.
Users from Bell Labs or ATT may be used to the Bourne shell, or an
extended version called ksh. If you want to use that, you can use the
command "chsh yourname /bin/sh". chsh changes your default shell.
You will normally be talking to the "top-level" shell, that is the shell that is created when you log in. However some programs have commands that create another shell. You would normally use one of these commands if you are in the middle of something and suddenly need to do an "ls" or some other command. When you are in one of these subsidiary shells, the "exit" command will get you back to the program that called the shell. If you have not set ignoreeof, ^D will also exit from a shell.
Normally what you type to the shell is the name of a program followed by arguments. For example, when you type the command "rm *.p" (which deletes all files ending in .p), this is really a request to run the program "rm". Normally, the shell looks on your own directory first to see whether you have a program called "rm". If not, it then looks on a set of system directories where commands are normally kept. That allows you to create your own version of commands, which you will get instead of the normal ones. If you want to execute a program from someone else's directory, you can give a name that specifies the directory, e.g. "/fac/u1/hedrick/rm *.p" would run a program from the directory "/fac/u1/hedrick". The exact list of directories where the shell looks is defined by a variable called your "path". To change it, you can use a command such as
set path = (. /usr/local/bin /usr/ucb /usr/bin /bin /etc)"." means the current directory.
The shell processes the wildcards, * and ?. So if you type a command such as "rm *.p", the shell looks in your directory for all files ending in ".p". It then run the program "rm", passing it an actual list of files, such as "lastprog.p prog1.p prog2.p". Thus means that individual programs don't have to have special provisions to deal with wildcards.
You can tell the shell to direct a program's primary input and output to something other than the terminal. This can be useful in case you want to put output in a file. For example, suppose you want to put a list of your files into "filelist". You could use the command
ls >filelistThe ">filelist" tells the shell to redirect the output from the "ls" program to the file "filelist". You can also redirect input, by using <.
You can direct one program's primary output directly into another program's primary input. (The device used for doing this is called a "pipe".) For example, suppose you have so many files that the "ls" command fills up your screen 3 times. You might do the following:
ls | moreThis directs the output from "ls" into the program "more". More is a program that prints its input, stopping every N lines (where N is the length of your terminal screen). You can construct long chains of programs in this way, e.g.
ls | sort | morewhich passes output from "ls" through "sort", and then to "more".
Many commands let you specify options. Normally options begin with a "-". For example, the "ls" command has options "-l" (long form listing) and "-t" (sort in order of creation time). You normally put options before any other arguments. Thus the following commands would be legal:
ls -l ls -l *.pThere are two different ways of specifying more than one option. Either you can specify the options separately, e.g. "-l -t", or you can combine them into a single option "-lt". Many commands accept either one. However you may run into occasional commands that require one or the other syntax. The documentation for each command describes the exact syntax that it is prepared to accept.
The following sections describe some more sophisticated features of the C shell. You may not want to read them the first time through. If not, skip to the next chapter.
The C shell allows you to run and keep track of more than one process
at a time. For reasons known only to the folks at Berkeley, the
processes running under control of the shell are known as "jobs".
This terminology is potentially confusing, since the term job is more
commonly used to refer to an entire session, i.e. to everything that
you are doing.
When you type a normal command, the shell starts the program you have requested, and waits until it is finished. If this were the only tool available to you, you could only do one thing at a time. You can interrupt a process by typing ^C, but this kills the process. So this still doesn't let you do more than one thing at a time.
The first, and most common, way to do more than one thing is to put a "&" at the end of a command. E.g. suppose you want to get a list of all the files on your directories, and you don't want to wait for this to finish. You might type
ls -R >files &The & specifies that the shell should start the command but not wait for it to finish. You can now issue more commands, and forget that the "ls" is still happening. A program that is running this way is "in the background". That is, it does not interfere with anything else you might be doing.
There is some question about what should happen to the terminal when a background job is running. In the example I just showed, the "ls" command sent its output to a file. But suppose you did "ls -R &". This command would still run in the background, and you could still proceed to do other things, but all the output from the command would come to the terminal. Since "ls" produces output continuously, it wouldn't be very practical for you to try to do anything else while it was running. The situation is even more interesting if the program reads from the terminal. Suppose a background program tries to read from the terminal at the same time that the shell is waiting for a command. You would have no way to know where your input is going to go. For this reason, the system will normally stop a background program when it tries to read from the terminal. The assumption is that you will eventually notice that the program is waiting for input, and will continue it as a normal "foreground" program.
The other way to get more than one thing happening at a time is the ^Z command. This stops the currently running job. But unlike ^C, it leaves the job around. You will be able to continue it later. Suppose you are typing a mail message and realize that you have to look something up in order to include it in the message. You can type ^Z. This will stop the mail program, but leave it around. You then look at whatever you need. You can come back to the mail program by typing "%mail". You can also continue a job in the background by doing "%name &". In the case of mail that wouldn't be too useful, since mail is going to need input from the terminal. But some programs ask a few questions and then go off and compute. In that case, you might run the program, answer the questions, and then type ^Z followed by "%name &" to get it into the background.
Before you can really use all of these commands, you need to know how to refer to a job. To get the terminology straight, let's start by looking at the output of the command "jobs":
geneva> jobs  Running ls -R /  - Stopped mail hedrick  + Stopped emacsHere we see a situation where there are 2 jobs stopped by ^Z and one running in the background. (It must be in the background, since otherwise I couldn't ever have typed the "jobs" command.) There are four different ways to refer to one of these jobs:
There are actually two different ways to continue a job. You can simply use the job name as a command, e.g. "%3" or "%emacs". Or you can use the "fg" or "bg" commands, which continue a specified job in the foreground or the background. "fg" and "bg" default to the current job. If you have just stopped a job, "fg" is probably the most convenient way to continue it, since you don't have to think about what to call it. But if you want to continue some previous job, it is probably easier to type a command like "%emacs", rather than "fg %emacs".
Two other useful commands commands that deal with processes are "kill" and "stop". Both of these allow either %name or %number. Kill also allows a system-wide pid. In general, kill is equivalent to ^C. That is, it gets rid of a job permanently. You would normally use it to kill a job that is stopped or running in the background. (If the job is running normally, you would just type ^C.) Some programs will trap the kill command. If you want to get rid of them, you have to use "kill -9", e.g. "kill -9 %emacs". This can be slightly dangerous. Normally processes trap a kill because they want to be able to clean up after themselves. If you use kill -9, they may leave temporary files lying around, etc.
The stop command is equivalent to ^Z. You would normally use it for a job that is running in the background. (It wouldn't make any sense for a job that is already stopped, and for a normal job, you would just type ^Z.)
Using the Documentation and Help Facilities
Unix has fairly complete documentation online. That is, for
each command or program, there is supposed to be a "manual page"
that describes it. To access these manual pages, you use the
"man" command. For example, "man ls" prints the manual page
describing the "ls" command.
In order to use the man command, there are some things you should know. First, for substantial programs, the manual pages are not complete. The intent is that they should tell you how to run things, but they should be short enough to read on your terminal. So "man pascal" will tell you how to run the Pascal compiler, and list all of the options. But it will not print out a complete Pascal language reference manual. There are separate manuals for the languages, the mail system, the document processors, and certain other complex pieces of software. Generally the manual page will refer to this separate documentation if it exists. Larger documents are normally put in the directory /usr/doc.
Second, the manual pages are organized into chapters. It is sometimes helpful to know what the chapters mean. For example if you ask "apropos" what documentation there is on "unlink" it will offer you man pages from sections 2 and 3. It is useful to know that section 2 is system calls and section 3 is subroutines. So if you were looking for the Fortran subroutine, you would want the one in section 3. Here are the chapters:
Note that Berkeley and System V used different numbering conventions, and this difference has carried over to Solaris. Solaris has additional suffixes for sections 1, 3, 4, 7, and 9. For example, section 1 has the following subsections under Solaris:
Section 3 has many subsections. Here are some of the more useful:
If you want to get an overview of what is in a given section, you can use a command like "man 3 intro", which will print the introduction to chapter 3.
You can get an overview of one of these subsections by typing a command like "man 3f intro".
The "man" command is useful for finding a description when you know what something is called. But suppose you want to remove a file, but you can't remember the name of the command that does that. The "man" command can't help you, because you don't know what to look up. "apropos" is designed for these situations. apropos searches an index containing the titles of all the man pages. It prints all title lines containing its argument. So "apropos remove" would print all title lines that contain the word "remove". Generally the title lines are written so that they contain most of the keywords people would use for looking them up. Of course you do still need to know something about Unix terminology. (E.g. you have to know to look for "remove" instead of "delete".)
By a judicious combination of "apropos" and "man", you should be able to find anything you want to about the system. What these will not do is give you overall system conventions, and the context you need to make sense out of these pages. (That is what this document is for.)
The man pages are intended to be fairly brief documents, that can be
read on a terminal. There are also full-scale reference manuals
describing the system and most of its software.
Many people it helpful to buy books about Unix or some Unix programs. Several local bookstores now carry a good collection of computer books (e.g. Borders). The publisher O'Reilly is particularly known for producing good books about Unix and Unix-related topics. If you want to learn how to write programs for X, their books are almost essential. They also publish detailed manuals about many topics related to system administration. However we don't know of anything that's good for just teaching you how to use Unix and debug programs. (That's why I've spent the time to write these handouts.) This set of online documents, plus the man pages, may be all you need as a general introduction. For complete novices, we sometimes recommend "Unix for Dummies". However it spends much of its time describing files and other basic concepts. People who have gone through the first semester computer science course shouldn't need it.
Editors: Creating and Changing Files
When you want to create a new program or change an existing one,
you will use an editor. An editor is a program that reads in a file,
lets you modify it, and then writes out an updated copy of it.
The editors that we use are "full-screen" editors. This means
that they display a piece of your file on the screen. In order to
change or add to the file, you move the cursor around the screen until
it is pointing to the place where you want to make the change. Then you
use editor commands to delete and/or insert things. The changes that
you make show up immediately on the screen. Of course it is also
possible to move the "window", i.e. to change which portion of the
file is showing on your screen.
When you are in an editor, you are actually working with a copy of the file. That is, the changes that you make do not show up in the file itself, but rather in a copy of that file that the editor maintains in memory. When you are satisfied with your changes, you instruct the editor to make the changes in the permanent copy of the file. Sometimes something horrible will happen while you are editing. If you want to forget all of your changes, you can exit from the editor without writing the changes back into the file. In this case, the file will not be changed at all.
Editors are very different in their commands from the rest of Unix. In most programs, commands are words or abbreviations. They are designed to be easy to remember and read. However in an editor, commands are usually single characters. Initially, this makes most editors look somewhat cryptic. However there is a good reason. You will be using the editor so much that you would quickly become tired of long commands. For example, if you want to move the cursor down 4 lines, it is very easy to hit the downarrow key 4 times. How would you like to have to type the word "down" 4 times? Normally commands are typed "in the dark". That is, you don't see the command on the screen as you are typing. Instead, you see its effect. For example, when you type a delete command, the character you are deleting disappears from the screen. You don't see the delete command itself.
Most of our users will use the editor EMACS. So the following section describes it in more detail. There are several other text editors available on the system. You can use any of them that you prefer. One advantage of EMACS is that it is available on almost every system at the University. It is also available for most common PC operating systems.
To edit a file using EMACS, just type "emacs filename". This works
whether the file exists or not. If the file does not exist, it
will be created the first time you use a command that updates the
You may get an error message "emacs: terminal "xxx" isn't powerful enough to run Emacs." Normally this means that the system does not know what kind of terminal you are using, or the type you have specified is not known. This probably means that you specified the wrong thing when you logged in. Try the command "echo $TERM" to see what the system thinks your terminal type is. You can change it to another type by using "set term", e.g. "set term = vt100".
The best introduction to EMACS is the EMACS tutorial program, "teach-emacs". To enter the tutorial, type the command "teach-emacs" from Unix command level. The following sections will give you a quick introduction, which should be enough to let you do some useful work.
In EMACS, there is no distinction between "command mode" and "insert mode", as there is in most editors. Whenever you type a normal printable character, it is inserted in the file immediately. The commands are all control characters or something equally unusual. Since you normally don't want to put control characters into your text, it is easy enough to tell what things are commands and what are text that you want to go into your file. So in EMACS, to add some new text, you just get to the right place and start typing. To execute a command, just type it.
As it turns out, there weren't enough different control characters to satisfy the designers of EMACS. They wanted more commands. So there are also some prefix characters that are used to make up 2-character commands. The most common ones are "escape" and "^x". "escape" following by anything is a command. So is "^x" followed by anything. (Escape is a special key, normally labelled "ESCAPE" or "ESC". On some older terminals it is labelled "ALTMODE" or "ALT".) Actually escape has one other use: escape followed by a number sets up a count for the next command. For example, "^d" deletes the next character. "escape 5 ^d" deletes the next 5 characters. [It's hard to write these key sequences. "escape 5 ^d" represents three keypresses: escape, 5, and control-d.]
The most common commands are put on a separate "keypad". This is a special set of keys to the right of the normal keyboard. On most of our terminals, the keys are labelled with the digits, and look like the keyboard of a desk calculator. When you use them in EMACS, you should ignore the labels. The most important keys are used to move the cursor around the screen.
what they do how they are labelled up 8 left right 4 6 down 2
Here are enough other commands to get you started doing useful work.
It is probably useful to give some additional information about some of these commands. There are two reasonable ways to add a new line. One is to go to the end of the line before the place where you want to put it and hit the carriage return to create the new line. The other is to go to the beginning of the line after it and hit "^o". In either case, the cursor will be left on the new line, ready for you to type in new text.
^k has a somewhat odd but useful definition. If you are in the middle of a line, it deletes the rest of the line. If you are at the end of the line, it deletes the newline at the end. That is, it joins the next line to the end of the current one. If you want to kill the whole line, this means that you should get to the beginning of it and do "^k" twice. The first time clears the line. The second time gets rid of the newline at the end.
^k can be used with ^y to move text around. When you kill lines with ^k, they are remembered in a "kill buffer". You can then to somewhere else and do ^y. This will cause the lines that you killed to be resurrected at the current location. You can put the same lines several places by doing ^y in several places. NB: If you do a few ^k's, then move the cursor, then do a few more ^k's, only the last set of lines killed will be in the kill buffer. Of course if you know how many lines you want to move, it is easier to do "escape 5 ^k" than ^k 10 times. (10 times because you have to type ^k twice to kill a single line.)
To exit from EMACS, first write out the updated version of the file by typing "^x^s", and then leave by typing "^x^c".
EMACS protects you against various kinds of disaster by keeping backup copies of your file. These have the same name as the original file, with .BCK or .CKP added to the end. If may find it a good idea to do "rm *.BCK *.CKP" now and then.
This document includes general-purpose commands. There are several
related documents that you will probably want to look at --