Quick & Dirty Guide to Getting Started in CSE 303

This is a modified version of this page.

Introduction

This guide tries to help you get ready to do the work for CSE 303. All it is about is "setting up your environment" (a semi-technical phrase) so that you can carry out the work and assignments that lie ahead. If you're familiar with Windows systems, imagine trying to write a guide that for some high school class that told them how to obtain and install Microsoft Office, and then how to launch Word and create a small document. On the one hand, it's not that hard. On the other hand, writing a guide can be very hard, and trying to follow it extremely frustrating, because there can be so much variability in the specifics of one system to the next. For your high school guide, for instance, you'll have trouble describing how to launch Word without considering whether the reader is running Windows XP or Windows Vista, and without considering whether the reader has the desktop style set to "Classic" or "Windows XP" or "Windows Vista." Once you've seen all this small differences, they're not big deal. When you're trying to follow a guide, because you've never seen any of this before, any small hiccup can be frustrating.

All of that is my way of saying that, in most cases, getting through this setup will be easy, but in a vey small number of cases it will be very frustrating, and probably there will be few to no cases in between.

Unix systems provide at least as much oppportunity for one system to look and act slightly different from another as do Windows systems. Even systems of the same variety of Unix (e.g., two Linux, or two OS X) can differ enough to cause trouble when you're a complete beginner (or even when you're me, with decades of Unix experience).

This all means that it's important that you work through this now. You can't do anything without verifying that your environment is set up, and it won't magically become easier to set it up later than it is now.

No where on our list of course goals is trial by fire, however. If you're having trouble getting things set up, definitely ask for help. You can ask us in class, in office hours, by email, and by simply stopping by. You can ask us and each other by using the course Wiki. If you work in our labs, you can also ask pretty much anyone else who happens to be in there with you - they're either in the same boat as you are, or they have been, and so will be at least sympathetic. (It might be best not to interrupt someone who is obviously intently fixated on some problem of their own, of course.) The kinds of problems that arise while setting up your environment are typically involve things you've never heard of, so a couple minutes talking with someone can fix problems that you could spend hours on yourself without fixing. (That last line is instructor speak for "start early, so you have time to get help if there are problems.")

Okay, onward.

Choosing a Machine For Your Work

My recommendations, in order, are: In some sense doing all your work on attu, and using whatever machine you find in front of you simply as a way to connect to attu, is the most flexible choice, because you can work from anywhere (in the world) without having to move files around. Additionally, we intend for any instructions we give to always work exactly as described on attu. Variations in machine configurations may make our instructions a little less reliable on other systems.

On the other hand, remote connection is one more thing you have to get set up correctly before you can begin doing any work. It can be confusing, if you haven't done it before.

Remote Connection to attu

We recommend you work in the basement labs where we have checked that the right software is already installed and the directions we provide are correct. If you still want to work elsewhere you have a few alternative options:

bash: The Shell

A shell is the program that reads and causes the execution of commands you type. It is what is running when you create a command window.

There are many different shell programs, which, confusingly, are often similar enough that things will work fine for a while when you think you're talking to one of them and in fact you're talking to another. Eventually, though, you'll type something that won't work if the shell isn't the one you meant to be running. For sake of uniformity in this class, we'll be using the shell named bash.

Which shell is launched when you create a command window is configurable by you. Unfortunately, the default shell launched before you configure is unpredicatable. So, the first thing to do is to verify that you are running bash

  1. Login.
  2. Open a command window. (How? It unfortunately depends on those thousands of details. If you're on a Linux box, look for a menu item called Terminal, probably under Applications/System.)
  3. Type ps at the prompt. That will cause a list of programs you're currently running to be printed.
  4. If you see bash, you're already running the right shell. If not (you'll probably see csh, a typical default shell) you can set your default shell to bash by typing this command:
    chsh -s /bin/bash
    That runs the "change shell" program and specifes that your new shell should be the program in file /bin/bash.
Okay, it's almost that simple. Not so unlikely things I know of that could go wrong: If you're having trouble getting your default shell to be bash, you can run bash anyway: just type bash to whatever shell is in front of you, et voila, you're now running bash. To exit the bash shell, just type exit (which will leave you back in the original shell).

Basic Unix commands

To move around through the directory structure in your command window, you'll need to know a few basic Unix commands. 
attu4% mkdir mydir
attu4% ls
mail  mydir
attu4% cd mydir
attu4% pwd
/homes/iws/sbfan/mydir
attu4% man man
attu4% exit
In the above:

Basic Unix Magic Keystrokes

A number of special keystrokes work most all the time, and can be useful. I'm not mentioning ones you might think to use in any case (like backspace, say), so you should try them, as well as others that seem like they might do something interesting. (Try the up arrow key, for instance.) The notation ctrl-X means hold down the control key while typing X. (All Unixes are case sensitive, by the way.) A warning about these: I put this list here just as a tiny safety net in case you get into a situation you don't understand, and just want out. (Try ctrl-c in that case.) They don't all always do what is claimed above - we'll learn why in a bit.

Emacs

Now that you have your xterm open, let's open Emacs. Emacs is an editor -- a tool that lets you modify the contents of files.

Type emacs & to open emacs in a new window. Note what happens if you don't type the "&"--you can't do anything in your xterm window. The "&" runs your program, in this case, emacs, "in the background." You'll get something that will look a lot like this (some details might depend on a thousand details of your configuration):

[GNU Emacs: a labeled diagram]

Emacs uses many key combinations involving the Control and Meta keys. Such key combinations are denoted C-x (Control-x (lowercase)) or M-x (Meta-x). On keyboards that don't have Meta, Alt is usually an acceptable substitute. If Alt doesn't work, ESC-x (ESC then x) is equivalent to M-x.

A sequence of key presses is written like C-a C-b M-x, which would mean do the three actions in sequence.

The most important keys in Emacs Getting help in Emacs (the next most important keys) Some other useful keys:

Font-coloring in Emacs

Remember the Emacs modes we were talking about earlier? The modes for shell-scripting and C programming do a pretty good job of coloring your code, but you may need to say you want that:
  • Get yourself a command window.
  • Type cd ~ to make sure you're in your home directory.
  • Type ls -a and look for a file named .emacs. You shouldn't have one (if you're not already emacs saavy).
  • Edit or create a .emacs file: type emacs .emacs
  • Paste the following line into your .emacs file: 
    ; get pretty colors
(global-font-lock-mode 1)
  • Save the file: C-x C-s
  • Quit: C-x C-c
That's it. To check if it works, you need to restart Emacs. Save your file (C-x C-s) and quit Emacs (C-x C-c), and open it up again. Open a file that starts with 
#!/bin/bash
(or create one, close it, and reopen it). Builtin commands like if and set should be in different colors - try typing them and see.

Accessing your Linux home directories from Windows XP

If you're in the basement labs, your O: drive should already be mapped to your Unix home directory. Look under for the O: drive under "My Computer" in the Start Menu. To accesss your files, go to O:\unix\homes\iws\userid, replacing "userid" with your own CSE account username. All the files you saved while working on Attu should be there.

If you're in the labs and your O: drive isn't mapped, open up a Windows Explorer window (by clicking the "My Computer" from the Start Menu) and in the Tools menu item, select "Map Network Drive" and enter O: for drive and \\ntdfs\cs for folder. Click Finish. If you're at a computer that does not use CSE's name servers, for example in Mary Gates Hall or at home, you will need to use the fully qualified name, \\ntdfs.cs.washington.edu\cs.

For more info on this, see the CSE support page that discusses Microsoft DFS, which is what we just used.

Other operating systems

Since we will grade your programs on attu and different computers can have frustratingly subtle differences, we recommend you do your homework there. That said, bash shells, emacs, C compilers, etc. exist for a variety of operating systems:

Again, we would like you to do your 303 work on attu, but using what you have learned on your own computer also makes sense.

Finally, there are other resources, including the CS Lab and Support pages.
Acknowledgment: These notes have evolved over the last few years, but are largely based on notes written by Keunwoo Lee in 2001. They started as a guide to CSE 341; information on SML has been removed and information on changing your shell has been added.