Go to the previous, next chapter.

Software in the Lab

There are only a few user accounts on the system. The two you should worry about are u6001 (with the inconspicuous password u6001, as the dialogue box readily reveals), which all 6.001 students use, and the hacker account, existing mainly for the purpose of unwedging students, the password to which will be given to you in the first LA meeting and as it changes. We will first discuss the student band, as you will spend most of your time dealing with it, then talk about the hacker account and privileges.

General Software Setup

When you login as u6001, an Edwin window (Scheme running Edwin) is automatically started for you. You will be doing most of your work inside the Edwin window, although opening an xterm might prove useful, especially when unwedging people. You can open an xterm (and, also, xclock and xload) by pressing the left mouse button and selecting the appropriate label.

As any respectable system would have it, there are three levels of abstraction you should worry about. At the bottom level is the underlying UNIX (also, the floppies use MS-DOS format). On top of that is bare Scheme, the manifestation of which is the so-called Edwin xterm window in the bottom right hand corner of the screen. Finally, there is the student Scheme environment, running Edwin (that is, your Scheme/Edwin process is the child of the process running bare Scheme--you can verify that by typing ps -ef in an xterm and observing the results). Edwin itself is written in Scheme. We will discuss the things you should know about each of the levels starting from the top.

Student Scheme/Edwin

The "Don't Panic" manual is a good source if you want to familiarize yourself with the student environment. In this section, you will find things that are not covered in the manual or those which we want emphasized.

Scheme Debugger

Learn how to use the debugger. As an LA, you will spend a majority of your time debugging students' code, so you should be comfortable with the Scheme debugger. Refer to "Don't Panic" for initial info. You will find (as soon as you stop whining that noone has taught you how to use the debugger and just try it) that it really is quite easy to use. For starters, write and try to execute a buggy procedure, answer y when prompted by Edwin on whether you want to enter the debugger, and type C-h m to get a list of commands.

You will find that sometimes--whenever a student's code runs on top of a big chunk of source code, as is often the case in problem sets involving graphics, for example--the debugger is not very helpful, since it mostly shows you what happens to the expression being evaluated as the source code, not the code the student wrote, is being run. The debugger is particularly useless if the source code is compiled, and it usually is. That is probably not a feature, but there is not much you can do about it. Try to get some information out of the debugger, but, if all fails, resort to some other method of debugging.

Encourage students to learn to use the debugger as well. Most of them have an inexplicable paranoia of it Fnord! which overtakes them and forces them to type n whenever the friendly Edwin tries to help out. Show them how easy it is; just a simple C-h m goes a long way. Teaching the students some of the basics will ultimately save you a lot of work, not to mention that it will deny them another excuse to use you as a human debugger and force them to be more independent.

Things to Look for when Debugging

While we are on the subject of debuggery: you will find that, especially at the beginning of the term, students will be generating many predictable, classifiable bugs. Infinite loops, for example, are usually rather obvious. Another common bug in the beginners' code is an unused definition (e.g., writing an internal iterative procedure without ever calling it). Later in the term, there will be quite a number of students wedging themselves by not being careful with their parentheses. An easy way to fix that is to always start your debugging by going to the beginning of the definition and typing C-M-q (next section describes this and other indentation commands). You don't want to spend half an hour staring at a piece of code only to realize that some parens were in the wrong place. Seems rather obvious when dealing with a LISP-like language, but an amazing number of people needs to be reminded of this particular feature of Scheme.

There are also some more obscure, but still rather common, error messages. "Anonymous arithmetic error" means a piece of compiled code tried to do some arithmetic and suddenly lost; it's usually caused by division by zero. If you find something else that pops up a lot, bring it up--there are usually different common bugs associated with different problem sets.

Useful Edwin Commands

Edwin is just a version of Emacs written in Scheme. Thus, most of Emacs commands work in Edwin. Here we remind you of the most useful ones (students usually neglect most of these and resort to the more primitive means of achieving their goals, which really is a pity; you might try to open the eyes of the more clueless ones and save them and, consequently, yourself a lot of time and frustration). They should be tatood upon the eyelids of the more clueless students.


C-n, C-p, C-f, C-b
Use these to move up (previous), down (next), forwards and backwards. Don't use the losing arrow keys.

C-a, C-e
Moves the cursor to the beginning/end of the line.

C-M-a, C-M-e
Moves the cursor to the beginning/end of the definition.

M-<, M->
Moves the cursor to the beginning/end of the buffer.

C-v, M-v
Scrolls to next/previous screen.

Multiple Windows

C-x o
Switches you to another window. You do not need your mouse to do this!

C-x 2, C-x 5
Splits the current window in two vertically/horizontally.

C-x 1
Deletes all windows but the current one.
C-x 0
Deletes the current window.

C-x ^, C-x {
When used with a numeric argument, allows you to extend the length of a vertically-split window/width of a horizontally-split window by a number of lines indicated; negative argument makes it shrink.

Buffers, Files, Directories

C-x b
Switches you to another buffer after prompting for its name (the default is the latest visited buffer). If the buffer doesn't exist, creates it. Some students get wedged when they use this command to create new buffers, since they expect a file under the same name to be created as well--this is not the case. Tell them to use C-x C-f instead.

C-x C-b
Lists all buffers.

C-x C-f
Finds a file (hit TAB to see your choices at any point); if the file doesn't exist, creates it in the current directory. This can also be used to get the directory listing--just hit RET after the name of the directory.

C-x C-s
Saves the current buffer to a file under the same name. If the file doesn't exist, asks you for the name of the file to write to.

C-x C-w
Saves the current buffer, prompts for a name of the file to save to.

C-x d (M-x dired)
Produces the directory listing. Hit C-h m for the commands in this buffer. Also, a short listing of files in the directory can be accessed by issuing C-x C-d.

Search and Query Replace

C-s, C-r
Prompts you for a string to forward/backward-search for (the default is the last thing you searched for). To continue the search, press C-s or C-r again. The students usually look for things by going up and down and up and down using the arrow keys--which is not very efficient.

M-x query-replace
Replaces one string by another. You will be given an opportunity to either make the change (press SPC) or not (press n) at every occurence of the string. Type ! to replace all the occurences.


Correctly indents (pretty-prints) the current line with respect to the previous line (another use of TAB is for completions; see below).

Indents each line of the following form (s-expression). This is an extremely useful command, since you can usually tell whether the parens are matched properly just by looking at the indentation.

C-M-f, C-M-b
Finds the matching parenthesis to the one the cursor is currently on. This, as you might imagine, is also quite helpful.

Killing and Yanking

Kills the character to the left of the cursor; does not enter it on the kill ring. Students love using it because it is so primitive. Don't wait for them for half an hour to delete a couple of lines like this; tell them about C-k.

Kills the character the cursor is currently on; does not enter it on the kill ring.

Kills everything on the line to the right of the cursor, putting the deleted text on the kill ring so it can be yanked later.

Sets the mark.

C-x C-x
The exchange point and mark command (point is where the cursor is). Shows you where the mark is.

Kills the marked region. To mark the region, set the mark at the beginning of the region with C-SPC and go to the end of the region.

Enters the region onto a kill ring without removing it from the screen; used to copy text as opposed to cutting and pasting.

C-y, M-y
C-y yanks the last piece of text on the kill ring (the text you deleted by the means of either C-k, C-w or M-w). After typing C-y, you can keep trying M-y to recall the text killed earlier.


Completes command names/filenames/etc. in the minibuffer; if several completions are possible, displays the choices available. Again, students usually ignore this and type M-x load-problem-set, for example, while, in fact, M-x lo TAB p TAB will achieve the same result; illuminize them, please.

When used in the `*scheme*' buffer, completes the names of procedures, both primitive and the ones currently defined in the global environment (actually, you can use this inside the debugger, too, in which case it is not the global environment, but the environment of the frame you are currently in--winning, isn't it?); also displays available choices in case of ambiguity.

Evaluating Scheme Expressions

C-x C-e
Evaluates the expression just before the point regardless of where it is in relation to the parentheses. I advise you to use this instead of M-z.

Evaluates the current definition (searches backwards for a left paren on the left margin, then searches forward to find its mate, evaluates the expression in between).

C-M-z (M-x eval-region)
Evaluates a marked region.

When used in a scheme-mode buffer, evaluates the entire buffer (any buffer with a name that ends in `.scm' is in scheme mode by default; otherwise, use M-x scheme-mode to change the mode to scheme mode). Cannot be used in the `*scheme*' buffer.

When used in `*scheme*' buffer, yanks the latest expression evaluated. May be used over and over to recall previously evaluated expressions.


M-x print-buffer
Prints the current buffer; the default printers are sicp-48 for machines sicp-02 through sicp-24 and sicp-49 for the rest. To change the default (in case one of the printers isn't working), type M-x set-variable RET lpr-switches RET '("-Psicp-49") to print to sicp-49, for example. To print without a header page, make that '("-h -Psicp-49").

M-x print-graphics
Prints the picture displayed in one of the graphics windows. You can specify which window to print from by either giving its name (what it is bound to in your Scheme) or clicking on it (the default option).

C-q C-l
Quotes ^L, which forces a page break on that line. C-q in general is used to quote things.

Help Commands

C-h C-h
Your basic help command; gives you a bunch of options and is pretty much self-explanatory.

C-h m
Use it to get mode-specific information.

C-h t
Activates the Emacs tutorial.

M-x apropos
Prompts you for a topic and delivers a list of commands including short descriptions of their functions on that topic. One of the most effective ways of getting help fast.

M-x manual-entry
This is equivant to Unix man command but nicer, because the manual entry is placed in a buffer which obeys Edwin commands.

Other Commands

M-x mail
Used to send (anonymous) mail.

M-x info
Activates the info tree; see Chapter 2 for more information.

M-x load-problem-set
Loads a problem set (the current one by default) into Scheme.

M-x checkpoint-floppy
Saves all the files in the `~u6001/work' directory onto the floppy in disk drive.

M-x logout
The proper way to logout.

M-x repl
If a `*scheme*' buffer exists, switches you there; else initiates a new read-eval-print loop (creates another `*scheme*' buffer). Useful when students wedge themselves by either killing their `*scheme*' buffer or saving it under a different name.

M-x scheme-mode
Puts the current buffer into scheme mode (this enables M-o, pretty-printing, etc.). All `.scm' buffers are supposed to be in scheme mode by default, but sometimes something funny happens. If M-o isn't working or things are not getting indented properly, try this command.

C-c C-c
Cancels the command; gets you out of whatever you were doing.

Bare Scheme

There really isn't much you need to know about the underlying bare Scheme. Sometimes the Edwin xterm window can be used to recover hung up Scheme processes, but that rarely works so don't count on it. Basically, typing C-g or C-c C-c inside Edwin xterm transfers control from the Edwin window to the Edwin xterm (you can then type in Scheme expressions at the REPL prompt and evaluate them simply by pressing RET). Type in (edwin) RET to return control back to Edwin. You can familiarize yourself with some other interrupt commands inside the Edwin xterm window by de-iconizing it and typing C-c followed by ?. See the chapter on crises for info on how these can be used to try to unwedge people's Schemes.

Beware that, since the window is readily available for people to play with, students will sometimes wedge themselves by doing just that. In particular, closing the Edwin xterm window will kill your Scheme process and log you out (this is probably the only way to really make yourself lose by not logging out properly--aside from totally wedging your Scheme--since C-x C-c is disabled in the student environment, and even closing your Edwin window is possible only after all the files you care to save have been saved, so they can at least be recovered.). Whenever you see students fiddling with the Edwin xterm, tell them not to.


This is the good old losing UNIX we all know and love. Use your xterm to talk to it (you can also open a shell with M-x shell and use that, but most people don't enjoy the experience).

The u6001 Home Directory

Most of the relevant files/subdirectories are located in the u6001 home directory. One such file is the `motd' file discussed earlier. The file is writeable by hacker but not by u6001, so you have to either be logged in as hacker or "su" to be able to make changes to it. Refer to the section on `motd' in an earlier chapter for more information on when and how the `motd' file should be changed.

The `~u6001/psets' directory contains all the problem sets. The file `probsets.scm', again writeable by hacker, is also there; you will need to edit it in order to change the default of M-x load-problem-set. See the relevant section in Chapter 2 for more information.

The `work' subdirectory is where the student's files are copied from his/her floppy if (s)he logs in with the floppy option. Needless to say, this directory is different on each machine, and students cannot access Fnord! each others' `work' directories, for security reasons. There are also three other subdirectories, `work.~1~', `work.~2~', and `work.~3~', used to store the work of the people who were the previous (most recent) users of the machine. This is a safety measure; it allows us to recover students' work when their Schemes get wedged, their floppies get corrupted, and other kinds of natural disasters happen. `Work.~1~' contains the work of the most recent user, and so on. These directories get shuffled on student login and logout--see the section below about what happens on login/logout for the exact procedure. Again, the files contained in these directories are not readable or writeable by students because of security issues, so you have to have hacker privileges to be able to recover their work.

Telnet and Ftp

You can telnet out of the lab by typing telnet destination from an xterm. To telnet to Athena, for example, type telnet athena.dialup or telnet athena-x if you want X applications. When prompted for the display you're using, type the name of the machine you are on--e.g., sicp-23. Telnetting into the lab is disabled, since we don't want strangers to use the most powerful machines on campus at the expense of 6.001 students.

Similarly, you can use ftp to transfer files to and from Athena or any other accounts you might have, by typing ftp destination.

"Su"ing to Hacker

To "su" to hacker when logged in as u6001, type su hacker at an xterm prompt. You will be prompted for a password. Be careful when typing it in; make sure the students don't find out what it is. Once the password is verified, you can do anything hacker can do (your Edwin window will still think you're u6001, but that shouldn't be much of a problem, as you probably won't be using it anyway). When you are done doing whatever it was you needed to "su" to hacker for, type exit. Don't forget to do this; if a student discovers (s)he has hacker privileges, a lot of damage can be done to the system.

Making Software Changes on Both Servers

There are 46 snakes in the lab, sicp-02 through sicp-47, not including the two servers, sicp-00 and sicp-01, and two printers, sicp-48 and sicp-49. That's 23 * 2, or 23 machines per server.(10) Machines sicp-02 through sicp-24 are connected to the server sicp-00 and the printer sicp-48, the rest to the server sicp-01 and the printer sicp-49. The most important consequence of having two servers is that all the software changes should be made on both servers, so that all the machines remain up-to-date. Synchronicity is your friend. You should remember that, specifically, when installing or making changes to the problem set code, editing the message of the day, changing the default of M-x load-problem-set, and altering other things in the entire system.

You have to be logged in as/"su"d to hacker while making the changes. If you are making the change from one of the sicp-00 machines--you are logged in from sicp-05, for example--changing the appropriate file will bring all the machines on that side up-to-date (i.e., the change will be made to the code on sicp-00, the server). To make the change on sicp-01 as well, type cp filename /nfs/sicp-01/users/u6001/filename at the xterm prompt. For example, to copy the `motd' file when in the u6001 home directory, type cp motd /nfs/sicp-01/users/u6001/motd. To make sure the change has been made correctly, do more /nfs/sicp-01/users/u6001/motd.


The floppy disks use an MS-DOS file format. This is nice, because students can work on their problem sets without having to come in to the lab--i.e., they can type the code in somewhere else, like an Athena workstation Fnord! or a PC, and use their lab time for debugging purposes only. If you know enough about DOS commands to use them to copy stuff to disk, etc. and want to fool around with them, more power to you--just make sure you don't make anyone lose in the process(11). Usually, though, the only command you need is M-x checkpoint-floppy (this is an Edwin command, issued from your Edwin window), used to copy everything in your `work' directory to the floppy. The only other thing I've found pretty useful so far that students often ask about is how to see the contents of your floppy disk: in an xterm, type dosls /dev/rfd:/.

While we are on the topic of saving files to disk: by the end of the term, checkpointing a typical floppy will prove to be quite a lengthy affair, since students will accumulate all their work from day one on their floppy disk. Please advise them that at least all the `.bak' (backup) and `.asv' (autosave) files can be deleted from the disk--this will speed things up quite a bit. Specifically, you can do the following:

  1. % cd work

  2. % rm *.bak *.asv (this removes files from the `work' directory)

  3. After you do this, when executing M-x checkpoint-floppy or M-x logout, you will be asked whether these files should be erased from the floppy. Answer yes.

What Happens on Login/Logout

The login/logout procedure outlined in this section has been changed around a lot ever since the system was setup. It is still unclear if it is the right thing. While the description below is accurate as of the time of this printing, it may change over time. The relevant files to consult for reference are `~u6001/.xsession' and most of the files in the `~u6001/bin' directory, such as `login', `logout', `rotate', etc.

When you are a u6001 user, on logout (this is a clean logout, caused by executing M-x logout) the files in your `work' directory get shifted over to `work.~1~'. The files in the other `work' directories get rotated accordingly. The events are, in this order:

  1. The `work.~3~' directory is deleted.

  2. `Work.~2~' is renamed `work.~3~'.

  3. `Work.~1~' is renamed `work.~2~'.

  4. `Work' is renamed `work.~1~'; protections are changed to make the new `work.~1~' directory unreadable by u6001.

  5. The new `work' directory is created, with appropriate protections.

It is unclear, however, what happens on an unclean logout--e.g., a Scheme crash--since the logout script may never have been run.

Therefore, there exists a mechanism run at login time which should detect unclean logouts, explain the situation, and ask if the user wants to recover any possibly unsaved work. If (s)he says yes, the script prompts for the hacker password. If the student answers no, the `work' directories are rotated as usual. See chapter 4 (the section on software crises, case 3) for details.

If someone somehow gets their files rotated away from them, there is a setuid script called `unrotate' in the `bin' subdir, that prompts for the hacker password (i.e., you needn't be logged in as hacker). To run it, type ~u6001/bin/unrotate in an xterm. This will do the obvious thing: move the work.~1~ files up to `work', and so on.

When you login as hacker, no rotations happen. Thus, logging in as hacker may be useful when recovering students' work, since you know for sure that it is still somewhere around--in the `work' directory if no rotation has been done, or in the `work.~1~' directory in case of proper logout. See the chapter on crises for more information on when to login as hacker and when as u6001, and on how to recover students' files.

Hacker Account

When you login as hacker, a Scheme process is not started for you automagically. If you want to start one up, open an xterm and type edwin & for a regular Edwin window or edwin -band 6001.com & for a student band (probably the only difference you'll notice is that you don't get all the silliness about the floppies, motd, etc. when using the regular band).

The `hacker' Fnord! home directory doesn't contain anything really interesting.

Be careful if and when you create temporary subdirectories in the `hacker', `u6001' or any other directory (sometimes you might want to do that in the process of recovering some student's files, for example). If the files contain anything resembling problem set solutions (and they usually do), make sure they are not readable by u6001 so as to not promote cheating. Try to avoid creating such subdirectories at all; there are usually ways around it. Similarly, if you are using the `hacker' directory to temporarily store your own problem set solutions, make sure they are not available for public use. And please clean up after yourself. Store your work on your floppy, or ftp it to your Athena account if you have to, but don't leave it hanging around.

There are really no advantages to logging in as hacker in non-crisis situations. (In times of crisis, on the other hand, it may prove necessary to do so, since logging in as hacker does not rotate the `work' directories, whereas a normal u6001 might. See the next chapter for more information on these kinds of situations.) When the lab is not busy and you find yourself spending most of your time at the terminal, however, you may use whichever account you find more agreeable. For one thing, the default size of hacker xterms is much more Fnord! sensible than the one used by u6001.

Go to the previous, next chapter.