Making your EWS UNIX account comfortable
v1.3.3

So UNIX kicks ass. But it does take a little bit of work to get to the point where you can truly appreciate the splendor of all that is holy and good about UNIX.

This outline is intended to help you with the initial setup work to make things comfy. It assumes you have basic UNIX knowledge, so if you don't then read Jason's tutorial first. The EWS also provides a manual with more detailed information. If you have any questions, or notice any omissions, contact Mike Perry.

Note that this tutorial is ENTIRELY OPTIONAL. You don't need to do this stuff at all to use these labs, but it makes their use a hell of a lot more pleasant.

Getting in

To get into the EWS labs, you will need to SSH into one of the Sun Solaris machines listed on the Labs page (any hostname that is of the form xx##sn.ews is a sun machine).

The best windows ssh client bar none is putty. For a replacement to FTP (to upload your files), you can either get psftp from that page, or use the graphical version in this file from ssh.com.

Changing your shell

So the default shell they give you sucks. The first thing you should do when you log in is change your shell with the 'chsh' command. I recommend either bash or zsh. I prefer bash, but zsh is available on all the UNIX machines on campus, so it might be easier to just pick it for all your UNIX accounts so you only need one set of config files. zsh also has some neat features that bash doesn't, but I like bash's default setup better.

Here's a .zshrc and here's a bash .profile that set your prompt all pretty-like with colors and the full working directory, and also set up a proper PATH for those shells. Download the one for the shell you chose and place it in your home directory and they will be run automatically each time you log in. (Files that start with . are called dotfiles, and are used for configuration of programs in UNIX. dotfiles are kept in ~ and are invisible unless you do 'ls -a').

NOTE: if you decide to use screen or rxvt (mentioned below), you'll want to 'ln -s .profile .bashrc' if you use bash. You don't have to do anything for zsh. Another reason to use it over bash. *sigh* I guess I should reconsider my favorite shell...

Finally! An editor that doesn't suck

Vim takes a little while to get used to, but once you learn it, you will never go back. I suggest putting this .vimrc file in your home directory before using it, though. It sets up syntax highlighting and autoindentation of your source code. Run the command 'vimtutor' to get a tutorial on how to use it. I've also defined a tab mapping in command mode that allows you to hit tab to properly indent that line of your code automagically like in xemacs.

One thing you won't see in the tutorial is that vim has the ability to keep track of all the functions in your program with the help of a utility called 'ctags'. Run 'ctags *.C' from your shell whenever you begin work on a new MP, and then whenever you come across a method call, you can do :tag Class::function inside vim to jump to the definition of that function. Hitting control-t pops one invocation of tag off the stack. This makes doing code review and tracing through your program flow easy as pie. (In C, you can do control-] over the function instead of :tag functionname, but right now vim can't resolve C++ method calls to the proper class).

vim also has a built-in help system that can be invoked with the :help command. :help will take arguments as well. For example, :help tag will give you more information about how that tag stack works. If you want to know about how to do something in vim, take a guess and try ':help sometopic'. Most likely it's in there.

Also, :make will execute make, and take you to the first error encountered. :cn will take you to subsequent errors.

Running a terminal that doesn't suck

So now that you know how to use an editor that doesn't suck, you're going to need a terminal that doesn't suck if you plan on doing any work from within the labs themselves. I suggest using rxvt over the default terminal on the UNIX machines.

NOTE: Because of the way bash sources .rc files, you'll need to 'ln -s .profile .bashrc' to get your settings to show up in subsequent terminal invocations (.profile is only read during login, and .bashrc is only read during non-login shells). Again, zsh users need not worry about this.

Running a remote X session

We will be using some graphical interactive debuggers in this class, so you probably are also going to want to set up remote X login if you want to work from home 100% of the time.

Xmanager was suggested by one of my students, but I've never used it. It has a 30 day free trial and supposedly their registration system is weak. But you didn't hear that from me ;)

I use Cygwin when I can't find a UNIX box in close proximity. Run their setup.exe, and install the XFree86 packages and also the WindowMaker, rxvt and openssh packages, and put "wmaker" in a .xinitrc file from the Cygwin prompt (NOT your EWS prompt!). 'echo wmaker > .xinitrc' should get the job done. 'startx' will then bring up the X server. You should then be able to click on the monitor icon on the right to launch a terminal, and then then run 'ssh -X username@xx##sn.ews.uiuc.edu' to log into the EWS machines. From there, you can run any program remotely and it will display in your local X server. To get rxvt to have a black background, run it thusly: 'rxvt -bg black -fg white'. This looks nicer with my vim setup, and white on black is easier on the eyes.

If you decide to use Cygwin, you no longer need putty. rxvt and ssh will probably work better for you. Also, xemacs will start in windowed mode, if for some reason you prefer that godforsaken piece of bloatware to vim ;)

NOTE: It's possible that running lots of X apps remotely can get you into bandwidth troubles if you live in URH. To try to minimize bandwidth use, run rxvt from the CygWin prompt and not the EWS prompt. This way window redraws aren't sent over the network. Also, if you add the '-C' flag to ssh before running apps remotely, it will compress all the forwarded window data, sparing you bandwidth.

Running screen

'screen' is a terminal multiplexer that allows you to run multiple virtual terminals in the same window.

The default command character is control-a. control-a c creates a new window, and control-a N jumps to window number N. Control-a a brings you back to the beginning of the line in your shell (which control-a used to do). If you want to keep control-a for going back to the start of a line, try downloading this .screenrc, which makes the screen command character alt-w instead of control-a and adds a nifty status bar at the bottom.

By far the biggest advantage of screen is its ability to remote-detach and then reattach. This is done with command d (alt-w d or control-a d). Reattach is done with 'screen -r'. This means that you can have a bunch of windows open, detach, go to some other machine, and reattach. It also means that if the machine you are using crashes for some reason (*cough* windows sucks *cough*), you can just let it reboot, relogin to the same remote EWS host, and run a 'screen -r' and you're back exactly where you left off. Cool, huh?

You may have to reset the TERM variable to dtterm in your shell each time you run screen. You can get around this by doing 'echo "export TERM=dtterm" > ~/.bashrc' or by doing 'ln -s .profile .bashrc' as mentioned above. There may be other terminal issues as well.. I'm still trying to figure out what's wrong with screen under rxvt in Cygwin.. If anyone figures it out, do share.

For more info, check out the screen manual

Using slrn

slrn is a cool newsreader that is installed on the EWS cluster. Here's a nice .slrnrc to download and place in your home directory which will give you a cool color scheme instead of the default black and white. All sorts of docs are available, but the main keys are 'a' to add a newsgroup, 's' to subscribe, 'enter' to read it, 'f' to follow-up to a post, and 'p' to post.

Common Problems

The most common problem is going to be mismatching of the erase character. When you use putty, it thinks the backspace character is ^?, where as vim (or more specifically, vim using the dtterm termcap entry) wants it to be ^H. To fix this, issue the following in your shell:

stty erase <control-v,backspace key>

Actually press control-v, let go, and then the backspace key in place of the stuff in <>.

You can add this line to your shell's login script so that you don't have to enter it every time. You shouldn't have to deal with this at all if you use Cygwin, though.

Also, slrn isn't installed on these machines. For now, if you want to use it, you'll have to ssh to the ews labs. Here's a .slrnrc file that makes slrn pretty.

Changelog