This document is designed to help a new student, of any level of computer literacy, get familiar enough with the Unix operating system to be productive with it. This includes file management, communication (primarily through the use of email) and also some background information to just familiarise themselves with other interesting and helpful parts of the system. It is not designed as a complete reference, or a command reference, and parts of it are specific to Lancaster University’s central Unix server as opposed to being generic.
While there are Graphical User Interfaces (GUIs) available for Unix, and available for use at Lancaster this document concentrates entirely on “shell accounts” or in other words logins that are text-only, this is because these will be far the more common method of accessing the Unix systems and can be done from anywhere.
The Unix system, also known as cent1, is provided by the University of Lancaster to help its students get their work done. It is a powerful, fast, centralised computer system that’s always available. This means that wherever you are, and whatever time it is you can always get to cent1 to run programs on it, or to get your files from it. It’s never switched off, or locked away, and it doesn’t matter if you’re in a lab, or a campus room or a room off campus, once connected to cent1 then you can do whatever you could from anywhere else.
The range of uses for the Unix systems are wide, you can use them for email, word-processing, software development, web browsing, reading usenet, the maths students use it to run matlab and the computer science department use it to teach Scheme and Java.
Before I progress any further in this document I’m going to write a quick section giving an outline of the differences between using a shell account and using a Windows machine in a lab or your room.
When you connect to the Unix systems at Lancaster you will get a load of text appear in the window, then you’ll see a prompt, essentially you type a command and press enter and that command is run. Once it finishes you see your prompt again and the system is ready to accept another typed command. Anyone who has used MS DOS, or the command prompt under Windows should be familiar with this method of interaction.
The above paragraph shows you how simple using a shell account is, however there are a few concepts to think about, primarily you must remember that although the window that has all the text in appears on your machine all the programs you’re running are being run on another computer. This means that you cannot directly access or affect the files on the machine that you are sat in front of with the commands typed into a shell.
While this may seem counter productive to be unable to directly affect those files, later on its shown how easy it is to move files between the Unix server and your machine (see section 4.10) also your shell on the Unix server will have its own files and directories to affect.
Also its worth remembering that while the machine you are logged into the Unix systems is generally only being used by you the Unix servers are being used by many users just like you, all at the same time, all with their shells running commands for them.
This document is a guide, and is designed to cover as many different topics as possible, in as much detail as is required to give the reader a fairly good grounding in the topic, as well as some pointers on where to find more information. If you skim over the index it should be fairly clear what each area covers and you should be able to jump to the correct part of the document. While it would help to read the thing from end-to-end I know that most people will blanch at this, the topics are fairly self-contained but reading some of the later ones without having at least skimmed the earlier topics will probably leave you fairly confused.
It should be available either via the web (in which case you’re reading this in your browser) or as a giant PDF file (in which case you’re reading this in either xpdf or Adobe acrobat).
Its usually available from:
http://www.lancs.ac.uk/ tipper/luui/unix-intro.pdf
Or in HTML form from:
http://www.lancs.ac.uk/ tipper/luui/html/
More information about it can be obtained from:
http://www.lanc.ac.uk/ tipper/luui/
Suggestions and corrections should be mailed to:
unixintro at lancaster.ac.uk
It was designed to be written in a fairly conversational and relaxed style and
some of the terms which might puzzle you can be found
in:
http://www.catb.org/jargon/
However it is also a technical reference and so precision is important. It should be noted that example commands for you to type in are shown like this:
% ls
Here the % (percent) symbol represents the prompt where you
type, you don’t type % before your command. “ls” is the
command being used and that is all you type, then you press enter to run the
command.
It should be noted that you’ll need to be careful about typing your
commands. They are all case sensitive, which means the commands “ls”
and “LS” would be two different commands.
Since most programs have names all in lowercase, and this case is important, for clarity these programs will always be written in lowercase. Even if the name of the program starts a sentence or title, it will be written all in lowercase.
As a last point about programs is that all program names can be verbed, for example you may find such sentences as “frank grepped for X” instead of “frank searched the output using the grep program for string X.”.
The other thing is that you will see a few sections that include notation like:
Then press ^d
What this means is that you need to hold down the control key (It
should be in the bottom left corner of your keyboard, it will probably have
the letters “ctrl” on it) and while you are holding that down press the key
listed after the ^ symbol as well.
In this case you would hold down control and press the ‘d’ key as
well, then release both of them. You’ll get used to doing this for several
things. It should be noted (especially in light of the next segment) that
while you will often see things writte ^D the program will in 99% of
cases accept a lowercase or uppercase d, just as long as you’re holding
down control.
Things that need to be typed exactly, and often the name of
programs to distinguish them from the text around them will also be shown in
the teletype font, these are things you should type exactly as you see
them written, and this font is used for clarity. These things may well also
be enclosed in “ and ” symbols.
After an example is given you will often see things like:
where “username” is the username you are interested in.
Here is is assumed that you will substitute the word username for
someones actual username, or some other piece of relevant information, such
words should not be in teletype font, to indicate you have to
change them to something else.
Also you may see sections of the text discussing “arguments”, “flags” or “options” to commands. An argument is a word that follows a command. For example:
% vim foofile
This runs the program vim with the argument “foofile”, generally this is used to give a list of files for a program to affect. In the example above it will open the file called “foofile” in the program vim and allow you to edit it.
A flag or option is a method of changing how a program runs, for example:
% ps
This will run the command ps in its normal mode of behaviour, however if you wanted to see more information you would use the following command:
% ps -f
Here -f is the “full information” flag, most of the time flags
are shown by having a - (dash) symbol in front of them, and no space
before the letter.
Quite often you’ll notice there are two sets of flags for a program, there are the short options with a single dash followed by a single letter (or perhaps two letters) and the long options, which are shown by two dashes followed without a space by a whole word. The short options are there to save typing, the long ones for clarity.
Information on how to get the lists of flags for a program is in section 3.5.
The author of the document has been a student at Lancaster University all through his undergraduate years as a Computer Scientist, and is a keen tinkerer with Unix, as well as an active member of LuBBs (Lancaster University Bulletin Board System) and so has quite a bit of exposure to the Unix systems here.
This document couldn’t have been completed without encouragement and editorial
suggestions from the LuBBs community (see 13.11). Also in particular
the following (in alphabetical order):
:DAN)
AZIRAPHALE
CARROT
HEDGEHOG
HOBNOB
STEREO
TERMINAL ADDICT
And surely others I’ve forgotten.