Go to the previous, next chapter.
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.
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.
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.
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.
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.
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.
- 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.
- 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.
- 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.
- TAB
- Correctly indents (pretty-prints) the current line with respect to the
previous line (another use of TAB is for completions; see below).
- C-M-q
- 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.
- BS
-
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.
- C-d
- Kills the character the cursor is currently on; does not enter it on
the kill ring.
- C-k
- 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.
- C-SPC
- 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.
- C-w
- 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.
- M-w
- 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.
- TAB
- 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.
- M-TAB
- 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.
- 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.
- 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.
- M-o
- 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.
- M-p
- 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.
- 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.
-
-
- 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.
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).
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.
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.
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.
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:
-
% cd work
-
% rm *.bak *.asv (this removes files from the `work' directory)
-
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.
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:
-
The `work.~3~' directory is deleted.
-
`Work.~2~' is renamed `work.~3~'.
-
`Work.~1~' is renamed `work.~2~'.
-
`Work' is renamed `work.~1~'; protections are changed to make
the new `work.~1~' directory unreadable by u6001.
-
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.
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.