Q. how do i access my cs account and change my password? is it in blackboard.ou.edu?
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
Q. I was just wondering if I missed the point where you told us how to login to the UNIX machines. I downloaded that teraterm SSH program, and I wanted to test it. Thank you.
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.).
Q. hi, which site are we suppose to login?
A. You may log in to any of the Computer Science UNIX machines.
These were listed on the handout distributed in class. They are
Q. i am visiting your course CS 3113 Inroduction to Operating Systems. Today i have tryed again to login at Sun-Stations in Felgar Hall, but with cs-password i haven't could do it, only with passMMDD. Perharps it was a false Computer Lab. Could you give me the Information, where i can change my password. I thank you for your help.
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
Q. I just wanted you to know that I have never delt with UNIX before in my life and I dont know if that is the case with some other students in the class...so I hope that you could explain with more detail in class cuz I feel lost when you are mentioning stuff about the commands to be used and other relative issues on UNIX.... but I did log on and changed my password and I did not like the interface of the system at all....it took me a while to guess...
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.
Q. I can login to the machines and everything, but then I cant really do anything. I mean, I dont know UNIX well, but I have tried to list the files and stuff like that, and nothing really happens. SHould there be files to be listed? Okay, I guess that when we get assignments, I will probably figure it out better. Thanks.
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
.., respectively. However, you aren't
seeing these when you use
ls because, by default, directory
entries starting with
. are hidden. To display these entries,
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
Some other commands you might want to play with are those for making a
mkdir), removing a directory (
changing directories (
cd), copying a file
and removing a file
(rm). You'll probably also want to learn
how to use an editor. Commonly used editors are
really is much more than a text editor),
vi (you'll probably
really want to learn
vim most of the time), and
Q. I succesfully
ssh-ed into one of the UNIX machines but
something wierd happens when I try to open a file. I used
to make a new file for testing purposes and it gave me an error
saying that it did not know any information on the terminal i was using
except that it was linux, and it told me to check out the terminfo
directory. I couldn't figure out what to do from there. Thanks
P.S. I was logging in from my linux machine and not from a windows environment
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
vi improved) or
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
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 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
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
gvim remotely, you need to have
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 firstname.lastname@example.org".) 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
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
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 "
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,
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
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
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
variable matches your terminal type and to tell
vim 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,
gnome terminfo entry from my Linux machine into
that directory (using
scp, a secure copy program that works
cp except that it can copy from one machine to
another), and set two environment variables. I set
/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.) Now
vim 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