Your CS account has nothing to do with blackboard or any other system. Your CS account is present on the CS machines in EL 158. You may access these machines by going to room EL 158 or remotely through ssh.

A. I hope the information given in class has answered your question. If not, please let me know that and on what particular point you are confused (for example, what the machine names are, what your username and password are, etc.).

A. You may log in to any of the Computer Science UNIX machines. These were listed on the handout distributed in class. They are gpel1 through gpel7 and turing.

A. The machines in Felgar hall and elsewhere on campus are not part of the Computer Science network. You need to go to EL 158 to use the machines directly or use ssh to reach them remotely. The machine names are gpel1.cs.ou.edu through gpel7.cs.ou.edu and turing.cs.ou.edu.

A. Thanks for your comments. You are not alone in the class in being new to UNIX. Things were easier a few years ago, when most students would at least have had some MS DOS experience. Since the MS DOS interface is, in large part, a cheap immitation of a UNIX interface, students would at least be prepared to use a command line interface (CLI). These days, many students have never used anything except a graphical user interface (GUI).

If you have specific questions about how to accomplish tasks on a UNIX system, please come to office hours and we discuss them and I can demonstrate them or, better yet, instruct you what to do and have you carry out the tasks yourself (so that you remember them better). I would also suggest investigating some the books on UNIX that I have listed on the class web pages.

I think your reaction to the interface is fairly typical. Most people don't enjoy it (i.e., get extremely frustrated with it) at first. Some people give up at that point. Others find out that they really enjoy it after they make it up the learning curve, and then start to get extremely frustrated with GUI interfaces that don't allow them the control or capabilities that they have with the UNIX CLI.

A. Probably things are happening but you aren't really seeing much anyway. For example, if you don't have any files in a directory, you won't see any files when you ask it to list them with ls. On the other hand, every directory contains at least two directory entries, one to itself and one to its parent directory. These are refered to as . and .., respectively. However, you aren't seeing these when you use ls because, by default, directory entries starting with . are hidden. To display these entries, use ls -a. The -a flag stands for "all." If you do this in your home directory, you'll see that it wasn't as empty as you might have thought. To learn more about listing directories, type man ls.

Some other commands you might want to play with are those for making a directory (mkdir), removing a directory (rmdir), changing directories (cd), copying a file (cp), and removing a file (rm). You'll probably also want to learn how to use an editor. Commonly used editors are emacs (which really is much more than a text editor), vi (you'll probably really want to learnvim or gvim; I usevim most of the time), and pico.

A. This is an excellent question that relates to several topics we will cover in this course.

First, I would suggest that, rather than using vi as an editor, you use vim (vi improved) or gvim (graphical vim). If you are used to using vi, both of these alternatives will seem very familiar in terms of commands (e.g., hit i to enter insert mode, hit <esc> to return to command mode) but they have some very nice features not found in vi. One such feature is what is called "syntax highlighting" (but would be better known as "lexical highlighting") which will show different parts of a file differently. For example, if you are editing a C source code file, it will show keywords such as if and else in one color, numbers in another color, comments in another color, etc. (I'll put on the class web pages an example of what the sample file for project 1 looks like using lexical highlighting.) This makes editing of the file much easier. Of course, this assumes that you have color display capabilities - with only black and white, lexical highlighting is limited to far fewer differences, such as normal text, underlined, and bold - and you probably won't get color if your terminal type is not recognized, which brings us back to your question.

One simple way around this problem is to use gvim. Because gvim does not use the terminal - instead it opens in its own window - it doesn't matter if your terminal type is not recognized. If you are not an experienced vi user, gvim also has the advantage that many common activities, such as loading and saving files, can be done by clicking your mouse on buttons, rather than using keystrokes. This will allow you to learn fewer keystrokes to begin with which will get you going more quickly. You'll still probably want to learn how to do these things from the keyboard eventually, however, because it is much faster.

To use gvim remotely, you need to have gvim running on the lab machines but displaying on the machine at which you are sitting. Because you are running Linux, this is easy to do. When you ssh to a lab machine, use the -X flag. (E.g., "ssh -X blow6789@gpel3.cs.ou.edu".) This will set up X forwarding (most UNIX and UNIX-like machines these days use the X-Window system and I believe MacOS X includes this as well) and any process you run that starts a new window will send commands to your machine's display.

You could also do this from MS Windows machines or older Macs or other machines but would likely have to add some additional software to make it work (e.g., XWin32 or MacX).

So, you can type "gvim &" and see the gvim window open on your local machine. Note the "&". It isn't necessary here but it is nice. It will cause gvim to run in the background. We'll discuss in class what it means for a process to run in the background but for now, note that the shell you have open on the remote machine will immediately prompt for more input. This means that you can continue using the terminal window for other things while using the gvim window for editing.

Another way around this problem is to use vim (or vi) but use it in a terminal that is running on the remote machine but displaying on your local machine (as opposed to your login terminal which is running locally, displaying locally, but getting its text from the remote machine). To do this, again connect using X forwarding but, instead of typing "gvim &", type "xterm &". What will happen is that a new X terminal will start up on the remote machine and send its display to your machine. When you run vim in this new terminal window, vim will recognize it, since the remote machine is configured to include information on this terminal type.

The down side to both of these solutions is that they will run too slowly over slow modem connections. If you are using DSL or Cable Modem you will probably be fine. An ordinary analog phone-modem, however, will probably be painfully slow this way.

The third way to approach this problem is to find out why vim (or vi) isn't recognizing your terminal. This has to do with environment variables. Look at your environment variables. There is probably one named "TERM". This is what vim is using to determine your terminal type. It will take the value of this variable and try to match it with the terminal types listed in the terminfo directories, which start at /usr/share/lib/terminfo/ and have single letter subdirectories which contain the actual terminfo files, sorted into directories by the first letter of each file. Since vim can't find a match for your terminal type it tries a default type which probably works to some degree but lacks many of the features that you'd like to have (such as color and maybe even the use of arrow keys for moving around).

You could try to address this by changing your TERM environment variable to match a terminal type that is listed in the terminfo directories. Unfortunately, if the terminal type you choose isn't a good match for your actual terminal type, it will probably behave very oddly and may even lock up.

The right approach is to ensure that your TERM environment variable matches your terminal type and to tellvim where to find a terminfo file for that terminal type. This is what I have done. I use Gnome Terminals from my Linux machine, so I created a directory /home/hougen/terminfo/g/ in my account on the CS machines, copied the gnome terminfo entry from my Linux machine into that directory (using scp, a secure copy program that works much like cp except that it can copy from one machine to another), and set two environment variables. I set TERM to gnome and TERMINFO to /home/hougen/terminfo. (I put these environment variable assignments into a login file, to ensure that they are set appropriately any time I log in.) Nowvim recognizes my terminal type and everything works well. Moreover, because other programs look at my terminal type as well, they now all recognize my terminal type and run as they are intended to. This is the reason that environment variables are there - so that when you change something in your environment, all of your programs discover the changes; you don't have to go in and reconfigure each program individually.