The GDB/XEmacs reference cards are here

Unix computing in the department: fiji/ceylon/sumatra/tahiti
There are four instructional Unix machines that are available for general undergratduate student use.  They are fiji, ceylon, sumatra and tahiti.  These four mahines run Linux -- which is a version of Unix (1).  They are bascially identical so it doesn't matter which machine you log into and use.  However, when you login, you will notice a message saying something like "Your home directory is on xxxx"  where xxxx will be the name of one of the Unix machines.  You may wish to log onto that particular one since it will be slightly faster.  However, functionally, you should be able to do the same thing on every machine.

/uns
/uns is a directory which stands for "unsupported."  This is a student run group which installs more up-to-date programs as well as some bells and whistles that will make using Unix easier and more enjoyable.  Amongst other things, they stock multiple window managers, text editors as well as a working c++ compiler.   Basically, the default programs aren't up to date, so if you want functionality in Unix, you will want to use /uns.  The Uber-Bench Environment below will setup your system to use /uns.  If you have any questions regarding /uns, you can e-mail the Undergradute /uns coordinator, Justin Husted (husted@cs).  Or, you can e-mail either of the two people listed above since they are also a part of the /uns group.  However, remember that /uns stands for "unsupported."  Most of the time, the /uns group will be willing to help, or fix problems, but they may not know of every problem and solution -- though you should still ask.

First things first: logging in
As you probably already know from using a C&C Unix cluster such as dante or saul, the first thing you're going to have to do is connect to the machine and log in. There are many ways to do this. If you're already logged in to a unix machine, simply type

ssh hostname

ssh -l username hostname

You should never use telnet to connect to a machine when you have a choice. The problem with telnet is that it's insecure - anybody running a packet sniffer program on the network can read your password as you're logging in. That is Not Good.

Changing your password
The command to change your password on unix is

passwd

Directories
If you know NT or the MacOS, you know that files are stored in folders, and that each folder can in turn hold other folders. The only real difference in Unix is that folders are called directories and, being Unix, it's all text-based. The command to list the contents of a directory is simply

ls

ls -a

Now that we can see the contents of our directories, let's make some new ones. The command to make a directory in Unix is

mkdir name

Like DOS, Unix has a notion of the "current working directory". This is the directory you are currently looking at, amongst other things. To find out what your current working directory is, use the command

pwd

Unix has another, more major difference in its filesystem. If you are familiar with Windows or the Mac, you know that those operating systems mount each drive as a separate file system. That is, drive C: has no relation to drive D:, and both have their "top level" directories. In Unix, there is only one directory structure - the directory tree, and the contents of a drive are simply mounted as the contents of a directory somewhere in the tree. The directory tree starts at the "root" directory, "/". As you can see from the output of pwd, the "homes" directory is preceded by a slash... that means it is contained in the root directory.

So now that we know something of the Unix filesystem, let's start moving around. The command to change your directory is

cd directory

These are all directories in the root directory. One of the more important ones for you as a Unix novice is /tmp, which is used as a place to hold temporary data (things get deleted after they've been in /tmp for a few days). Stuff in /tmp won't count against your disk quota - which, by the way, is 60 MB. Other directories you may find yourself diving into soon are /cse, which holds information for the CSE classes, and perhaps /uns (more on that later).

A special directory we can always change to is the last one we were in. The command to do that is

cd -

Because home directories are so important in Unix (it's where you'll store the vast majority of your files), there are many ways to get there. The easiest way to get back to your home directory is to just enter the cd command without arguments. A second way is to use the special shell symbol "~" (more on shells later). When you type "~" on the command line, that will expand to be the path to your home directory. On the other hand, if you type ~user, that will expand to be the path to user's home directory. Go ahead and change to my directory: "cd ~evgenyr". Run pwd to see how the path to your current working directory changed.

Remember the directory "foo" we made back in your home directory? Let's go back there. You could use one of the variety of ways to change to your home directory, and then cd to foo. But the easiest way is probably to "cd ~/foo". If you're confused as to how that works, ask your neighbor.

Now that we're back in the directory we made, do a full listing (ls -a). Note that when you show all files in this directory, the listing contains two entries despite the fact that we never made any files here: "." and ".." These are two special "files", common to every directory. The single period refers to the current directory, and the double period refers to the parent of the current directory. Keeping with the directory tree line of thought, the "." file can be thought of as a pointer to the current node, and the ".." file as a pointer to the node's parent. So now we have two more special things we can change our directory to: "cd ." and "cd ..". The first is pretty useless - it says to make the current working directory what the current working directory already is. The second is quite useful - it says to bring the current working directory one level closer to the root directory.

Shells, processes, and the kernel
So you may be wondering by now what's going on here. How is it that a few dozen people are using the same machine at the same time? The answer is that Unix is a true multiuser operating system - it was designed from the start to allow multiple people to use the machine at once. The way it works is to put the core parts of the operating system - the stuff that handles disk IO, memory management, networking, etc. - into a section called the kernel. Users such as yourself do not interact with the kernel. Users interact with their shell, which in turn interfaces to the kernel.

So what's the shell? When you see your Unix command prompt, what you're really seeing is your shell asking you want you want to do. When you tell it to run a command, it will then go ask the kernel for you. The shell is what is known as a "user-level process", which basically means it's a program running at your behest. (This is as opposed to a kernel-level process, which is more-or-less a program running at the request of the system, not one particular user.) As you tell your shell to start other programs, it spawns off other user-level processes which also run on your behalf. This may seem somewhat needlessly complex at first, but in the 30-odd years Unix has been around, this has proven to be a very scalable, secure, and stable model to follow.

You can see what processes you are currently running with the ps command. Passing ps the -x flag will also show processes that have lost contact with the shell that started them - which usually happens when you log out and, for some reason or another, a program you were running thinks it can't quit. Sometimes you would like to kill a program that has become braindead, in much the same way like you can terminate processes in NT. The way to do this is with the kill command:

kill pid

Besides starting processes for you, the shell also keeps track of environment variables (such as your execution path) and aliases. Environment variables are variables you set in the shell, which it turn makes them available to programs you run. The execution path is the set of directories the shell searches for a program name when you type a command; it is stored in the PATH environment variable. When you want to get at the value of a shell or environment variable, you must proceed the variable name with a dollar sign. For instance, if you want to see what your execution path is, you can use the echo command (which does the highly complex task of printing out its arguments):

echo $PATH

echo PATH

Aliases are shortcuts to save on typing. You can see which aliases you currently have set by simply typing "alias".

Like everything else at the user-level in Unix, a shell is just a program that anybody can write. As such, there are many available, each focusing on a different set of features, efficiency, and design philosophy. Shells are an issue of some contention in the large and fractured world of Unix. Because the operating system has had 30-odd years to form a variety of subcultures, over time certain camps have developed a fond attachment to their shell of choice. This leads to one of the major Holy Wars in the Unix world: which shell is the best to use.

There are two main contenders for Best Shell, tcsh (The C SHell) and bash (Born Again SHell). In my totally unbiased opinion, bash is by far the better of the two. Unfortunately, CSE support installs tcsh as the default shell, and they do not allow you to change this. However, this can be worked around, as we shall do shortly. Keep in mind that a shell is really just a program, so you can start a new shell from the command line. Right now you are almost certainly working in tcsh (running ps will confirm this), so start up bash by typing "bash".

You know you're in a new shell because your command prompt will change, probably to "bash 2.03 $" or something similar. Let's try adding something to our execution path. Type

export PATH="$PATH:/uns/bin"

Pagers
Another difference between shells is their set of configuration files. These files are responsible for automatically setting a shell's environment upon login, which includes things such as the format of the command prompt, environment variables such as PATH, and aliases. Because support sets the default shell to tcsh, you are using tcsh whenever you login.. tcsh looks at a pair of configuration files, ".login" and ".cshrc", both of which are stored in your home directory. (Remember the leading period in these filenames means you can't see them with ls unless you pass ls the -a flag.)

An easy way to view these files is with the "cat" command. cat stands for conCATinate, because it does a lot more than just viewing files. However, it also views files quite well. Try it out by getting to your home directory and typing

cat .login

Pagers are programs which let you scroll through a text file one screen at a time. The most common pager is called "more", and works like "more filename". Use more to view your .cshrc file. The space key pages down a full screen at a time, while the return key moves down a line at a time. The "q" key quits more and drops you back to your shell prompt.

The biggest problem with more is that it only lets you see more of the file.... you can never scroll back up. A newer replacement for more is a program called "less". less works exactly the same way more does, except it will let you scroll back up if you hit the "w" key. less will also let you search for strings if you type a slash followed by the string.

Copying, Moving, and Removing Files:
Let's say, for some reason, you want to make a backup of your .cshrc and .login files. To do so, you would want to copy the files to another location. First off, let's start by making a directory called backup

mkdir ~/backup

now, you want to copy your files. The copy command in Unix is

cp source destination

cp .cshrc ~/backup/.cshrc

That will copy the .cshrc file to ~/backup/.cshrc. You could do the same thing with your .login file, but there is an easier way:

cp .login ~/backup

The cp command is smart enough to see that the destination is a directory. It will automatically assume that you mean to copy .login to ~/backup/.login. This is infact the prefered way of doing things since it help avoid typos. As for moving files, it uses the exact same commands.

*Be careful with cp and mv - if you specify a destination that already exists, Unix will happily overwrite it and not warn you.*

Now, since there really was no reason to make backup copies of your .cshrc and .login, we should delete this extraneous directory. First, change directories to ~/backup

cd ~/backup

Then you can delete the files using the rm command:

rm .cshrc
rm .login

Now, removie the backup directory by moving up a directory:

cd ..

and removing the directory.

rmdir backup.

*As with cp and mv, rm will also delete file without and warnings!!  Make sure you really meant to delete something since there is no undelete feature in Unix*

Getting the Uber-Bench Bash Environment with Evgeny's Enchancements
Configuring your shell isn't that hard if you read up on the documentation, but it's frequently quite tedious. There is a preconfigured shell environment named after its creator Ben Chabot (bench).  It has been given a major overhaul by Evgeny and provides a fairly decent setup.

Evgeny has put together a little script (a automated set of commands) that will do all the setup for you, and more. It is currently the recommended way to setup the environment since it is easier than trying to do it manually. The script will switch you into bash and will give you some decent X-Windows as well as emacs defaults. Also, it setups up your cp, mv and rm commands to warn you before you overwrite files.

Evgeny's Unix Environment Setup Script instructions:
To setup the environment, it's quite simple. Just type:

/uns/bin/setup-tutorial

and most everything should be done for you.  If you have started playing with X, and you wish to change your window manager, use the command

chgwm

and follow the onscreen instructions.
Note: The second command will not work unless you've done the first one at some prior time.

X Windows
Now that you've copied over those two files to your home directory, you may be wondering why nothing has changed. The reason is because those configuration files only get read when you're starting a shell. An easy way to get the files to be re-read is to log out and log in again, which provides us with an excellent excuse at this point to introduce the X Windows system.

While it's true that Unix is, at it's heart, a text only command line operating system, it does have the capabilities to do graphics and even have a graphical user interface through the X Windows system. When you use X, the computer you sit at becomes for all intents and purposes nothing more than a monitor, mouse, and keyboard attached to your Unix machine over a network.

The CSE department has a few X terminals, which are exactly what they sound like, and all the NT boxes have X software installed called ReflectionX that lets them emulate an X terminal.  Go ahead and log out of Unix, and then log in again using ReflectionX or an xterm if you feel like being hardcore. Unfortunately, ReflectionX has not been configured extremely well by support, so if you're having problems logging back into fiji, ceylon, sumatra, or tahiti, snag somebody and ask for help.

One of the great things about X is that it lets us make our command windows bigger, so we can see more at once. (There are, in fact, many great things about X, and this might well be a subject for future tutorials.) After you log in, go ahead and start an xterm, then make it as big as you want.

If you copied over the Uber-Bench Bash Environment, take a look at what's different. The first thing you'll probably notice is the prompt has changed; it now shows the host you're logged into followed by your current working directory. Change directories a few times and see how the prompt changes as you move.

File editing
A rather important thing you'll find yourself doing a lot in Unix is editing text files. Like shells, there are lots of different text editors, each with its own tradeoffs in power, ease of use, size, and goals. Even more so than shells, "discussion" of the best text editor is a major Holy War in the Unix world.

On the CS department machines, you have a choice of vi, vim, emacs, pico, nedit, and more. Vi is a full-screen editor that borrows the concept of "modes" from line-at-a-time editors that preceeded it. The ordinary characters you type can be either inserted in your file, or interpreted as commands, depending on the "mode" the editor is in. You switch from the "insert" to "command" mode by hitting ESC. This takes a bit getting used to, but Vi can be extremely fast and flexible in the right hands. A group of enthusiastic Vi users decided to give it a graphical user interface, syntax highlighting, menus, mouse interaction, extended scripting language, and other bells and whistles, and thus Vim (Vi Improved) was born.

Meanwhile, somewhere in the depths of the Artificial Intelligence lab at MIT, a very different editor was being developed. The name Emacs stands for Editing MACros, because originally the author just collected a bunch of "macros" (command sequencies) for a text editor called TECO. Emacs inserts the characters you type as you type them, so it needed some other way to take commands. The author decided to use a combination of Control, Meta (Alt or ESC on most keyboards) and ordinary letters to issue commands. The author also endowed that editor with a dialect of Lisp as an extension language. Eventually, people found that they could do quite a bit besides just editing text with the Emacs Lisp language, and so modern distributions of Emacs come with everything but a kitchen sink. Emacs aims to be a complete working environment, rather than just a text editor: current versions of Emacs can read mail and news, run the shell, the compiler, and the debugger, make it easy to access files via FTP, and can serve as a Web browser, among other things.

Pico is a very simple editor, that should be familiar to you from using Pine (it's the editor you use to compose your email), and nedit "feels" very much like an MS-Windows application, so hopefully neither one takes too much more explanation, Just try them, if you are curious. When choosing an editor, please be aware that vi and Emacs are pretty mainstream, while vim, pico, and nedit are much less wide-spread, so your knowledge of those other editors may or may not transfer easily to Unix systems outside UW.

Due to a fork that occured in the Emacs development during the early 90's, there are two versions of Emacs in widespread use today. XEmacs is nicer-looking (more 3D-ish), has better menus, has toolbars, can display images when ran under a window system, supports colors when ran in a terminal window, and is probably easier to get started with for the novices. There are people who prefer GNU Emacs over XEmacs, for its more consistent (albeit more spartan) feel, and smaller memory footprint. Some GNU Emacs users also cite faster interactive response.

If you plan to use Emacs for any length of time you really should take the time to work through the Emacs tutorial. Just type C-h t, or select the tutorial option from the Help menu. The tutorial will probably take you a couple of hours to work through from start to finish, but it does give a very good grounding in Emacs.

Now that we know how to edit files, let's edit something that's somewhat useful. A standard Unix program is called "finger". finger looks up information on somebody. For instance, you can finger me by typing

finger bench

You don't have to finger people by username, either. You can finger a last name or even a first name, and the system will simply finger everybody that you might have been talking about. For instance, try to "finger Ben", and see how finger deals with the request.

The whole point about finger is this: if you have a file in your home directory called ".plan", finger will print out the contents of that file when you are fingered by somebody. (Finger will also print out the contents of a ".project" file if it exists.) You don't currently have a .plan or a .project file, so move to your home directory and fire up pico to make one:

pico .plan

Some better ways to do that is to remove the .forward file after copying it (the Unix command to remove a file is rm), or even easier, just move .forward to .forward.old (with the mv command). Be careful when using rm - Unix assumes you know what you're doing, so it doesn't ask you if you really want to delete a file, and there's no way to recover it short of backups.
 

Permissions
You may be wondering, now that we have all this power of file editing, how come our files are safe from tampering if the entire CSE undergrad population is pounding away on the same filesystem. The answer is permissions. Every file and directory in Unix is owned by a certain person and a certain group, and has a set of permissions attached to it that allow access to its owner, its group, and everybody else. If you don't fit into a category that has access, you can't access the file or list the directory. In addition to those three sets of permissions, there are three different kinds of permissions: read, write, and execute.

It's undoubtedly time for a concrete example. The way to see file permissions is to tell ls to output a long listing by passing it the -l flag. Go ahead and list everything in your home directory as a long listing:

ls -al ~/

The first few lines you'll see will probably be similar to
 

drwxr-xr-x	16	bench	ugrad_ce	2048	Oct 12 01:29	.
drwxr-xr-x	58	root	root	1024	Oct 10 16:35	..

The first column is the permissions for the files. "d" means the file is, in fact, a directory, and if you had copied over the Uber-Bench Bash Environment, the filenames for these two lines will be showing up in bold green, also indicating they are directories. The next three letters, "rwx", are the permissions the owner has over this directory... in the case for both these directories, Read, Write, and eXecute. The next set of three letters are the same as the first set, except they're for the directories group. The final set of three letters is for everybody else on the system. In a nutshell, what the permissions for these directories say is that owner has full control, while those in the directory's group and everybody else can read and execute but not write.

The second column is uninteresting - see the documentation for ls if you're really curious, and look for information on inodes. The third column is the username of the file's owner, while the fourth column is the name of the file's group. In the listing above, I own the current directory, which also belongs to the group ugrad_ce, while root (the system administrator account in Unix) owns the parent directory.

The fifth column is not very informative for directories - think of it as a very rough indication as to how much stuff is in the directory. For files, it's the filesize in bytes. The second to last column is the last time the file was modified, and the last column as you've surely guessed by now is the filename.

There are a couple other things you may see when listing files with long listings:
 

-rw-r--r--	1	bench	ugrad_ce	1766815	Sep  7 17:56	ants.ps
lrwxrwxrwx	1	bench	ugrad_ce	3	Oct 12 02:22	bar -> /tmp/foo

The first is a normal file.... notice that the first character in the first column is a dash. It is owned by me and the group ugrad_ce, it's 1.7MB in size, I haven't touched it in awhile, and it's called ants.ps. The second is what is known as a symbolic link or symlink... it's similar to a shortcut in Windows or a file alias in the MacOS. Note how the first letter if the first column is an "l" (for link) and everybody has full permissions. Keep in mind that while everybody may have full permissions to follow this link, they may well not have full permissions to whatever the link points at. Symlinks are quite small - this one takes a whopping 3 bytes of storage. The last interesting thing about this is the filename. The link itself is called "bar", and the file it points to is /tmp/foo.

You can change permissions for a file with the "chmod" command. If you need to change permissions, feel free to consult the documentation. (More on this mythical "documentation" later.)
 

Printing
The basic command to print in Unix is

lpr -Pprinter <file1> <file2> <file3> ...

lpr -Pps329 -Z duplex sample_hw

An even better way to print text files (not postscript files), assuming you copied over the Uber-Bench Bash Environment, is to use the elpr alias. You might want to type "alias" by itself to see what elpr is defined as.... basically, it runs a program called enscript which puts your textfiles into a nice, easy to read, paper-saving format. You use elpr the exact same way you use lpr, except you don't need the -Z duplex arguement to print on both sides of the paper. Back to printing out the sample_hw example...

elpr -Pps329 sample_hw

lpq -Pprinter

lprm -Pprinter job number

Archives: tar and gzip

Under Unix files are usually distributed as compressed archives, so you can expect to find your class projects being distributed that way. In contrast to most DOS/Windows tools (such as Winzip), Unix has traditionally separated the task of archiving (producing one large file from a set of files) from the task of compression (making files smaller). The most widely-used unix archiving program is tar (which stands for Tape ARchive), and the most widely used compression program in the Unix world is gzip. The GNU version of tar, installed on Linux machines in the department, will run gzip for you if you tell it to. Tar archives compressed with gzip are usually easy to recognize because their names end in .tgz or .tar.gz (but that's just a convention: file extensions under Unix don't nearly have the significance they do under Windows).

Given a .tar.gz file, you can list its contents with:

tar -tzf somefilefile.tar.gz

t

tells tar to list the contents of the archive (the - that precedes it is optional).

z

tells tar to run the file through gzip to decompress it

f

gives the name of the file to work on: tar, being a Tape ARchiving program after all, will attempt to read some obscure tape device that probably isn't even connected to the machine, unless you give it the -f option.

Extracting the files is quiite easy also:

tar -xzvf filename.tar.gz

The shell revisited: Helpful Stuff
A command line interface such as the shell prompt can be amazingly powerful, but let's be honest - nobody likes to type, especially when it involves typing long, tedious filenames. Hence the Uber-Bench Bash Environment has good defaults set for tab completion of filenames. If you start to type a filename and then hit the tab key, the bash shell will complete as much of the filename as it can. If there's an ambiguity, it'll stop there. Hit tab a second time, however, and it'll show you what your choices are to complete the filename. All you have to type is enough to distinguish between those, and another tab key will finish the typing for you.

Another feature that's helpful when dealing with multiple files is something known as "globbing." Globbing gets pretty esoteric pretty fast, but in it's most useful and simple incarnation, it consists of the splat symbol (*), known in more proper circles as the asterisk. Splat will match zero or more of anything, so typing "foo*" will match all files that start with foo. Typing "foo*bar" will match all files that start with foo, but only if they also end with bar.

Just in case you don't feel scattered enough, good Unix shells also give you the ability to run many things at once with a mechanism called job control. Only one program can be in the foreground, but any amount number be either running in the background or sitting in suspended animation. There's no inherent speed advantage to running a process in the background under Unix - as far as the kernel cares, it's just another process to handle.

To see this in action, start up netscape by typing "netscape". Eventually, and assuming you've logged in via an xterm or ReflectionX, netscape will draw its window to your screen and you can merrily surf the web. But then say you want to edit a file at the same time. Go ahead and move the netscape window out of the way of your shell. Notice that netscape is still hogging the command line! It is running in the foreground, and until we get it out of there, our shell can't get any new input from us.

You suspend a program by hitting control-Z. Pressing that in you shell window should give you a message that netscape was suspended, and more importantly gives you back a command prompt. But keep in mind that this puts netscape into a state of suspended animation - while you can use the shell, you can't do anything with netscape, because it's not getting any CPU time. You can run the command "jobs" (aliased to "j" in the Uber-Bench Bash Environment) to see the state of your running jobs.

To put a suspended job in the background, type bg. Netscape is now running happily in the background, and we still have our shell prompt. Similarly, we could have put netscape back into the foreground by typing fg instead of bg, but then we would have sacrificed our shell prompt again. Once you get lots of jobs suspended or running in the background, you can bring specific ones to the foreground by type %job_number. You can also start a program running in the background instead of in the foreground by appending an ampersand to the command. For instance, to start netscape running in the background, enter

netscape &

Finally, two very helpful but somewhat advanced shell features are pipes and redirects. A pipe is a way to use the output of one process as the input of another. It is denoted with a pipe (|) between the two commands. For instance, say I wanted to do a long listing of a directory with a lot of files in it. Just typing "ls -l" will cause the files to scroll off the screen. Instead, I could enter

ls -l | more

Redirection is similar to pipes in its simplest case, except that instead of sending the output to another process, the output is sent to a file. This type of redirection is denoted with a single right angle bracket (>). Using the above example, say I didn't want to look at the files at this moment, but instead wanted them in a file. I could enter

ls -l > listing

Some standard tools
I cannot hope to scratch the surface of all the useful tools in Unix during this intro; however, there are some standard ones that you will almost certainly find quite helpful. The most important one of them all is the way to access all this documentation I've been referring to along the way. Manuals for Unix are stored online, and are accessed via the command "man". For instance, to see more information about the program ls, you look at its man page by typing "man ls". Want to do a keyword search through the man pages? Pass it the -k flag. So, if you wanted to see what programs were installed that dealt with postscript, you could type "man -k postscript".

Some notes about man: The Unix man pages are split up into different sections, which is why you always see a number after the subject for each man page. Section 1 is basically stuff you can run as a system user. Sections 2 and 3 are programming interface documentation. Section 8 is generally system daemon and protocol documentation. Unfortunately, just because there is a man page for a program doesn't mean it's necessarily installed. Similarly, not every installed program has an associated man page.

Another program you'll likely find useful is grep, which lets you search through files to find regular expressions. For instance, to find which files in the current working directory the string "howdy" shows up in, I could enter

grep howdy *

You can find a file in the Unix filesystem with the find command. It takes the format

find start_path -name name_of_file -print

find / -name "*bench*" -print

Finally, you should know that find is quite resource intensive and takes a while. If the file you're looking for is at least 24 hours old, it's been put into a large hash table which can be searched by the locate command. locate is very quick, but because it builds it's database nightly, it's not always as current as possible. The syntax is simply

locate string

locate bench

• The XEmacs v20.x reference card
• The GDB reference card

footnotes

1. This is a lie. Strictly speaking, Linux is not Unix -- it was written entirely from scratch and has no relation to Unix invented by AT&T, other than the two happen to feel very much alike, however we'll use "Unix' to refer to Linux systems throughout this page.