CSE 332S: Object Oriented Software Design Laboratory

Spring 2008: Lab 0

Due 11:59pm, January 23, 2008.

Purpose

The purpose of this lab is to make sure that you're familiar with the linux lab, linux, and some of the tools that we'll use for this class.

Preparation

  1. Find the linux lab, Lopata 400.
  2. Go there and take a seat.

Assignment

If there is any part of this lab that you don't know how to do, remember that you can ask one of the CEC staff for help. You can also (for this lab) ask the person sitting next to you. Remember, too, that is your friend.

  1. Login to one of the CEC linux lab machines, and open a shell window.

  2. Find out about the manual pages:
    man man

    Look up printf and read a bit about it.

  3. Find the class message board. Post a message on the message board with your name and an advertising slogan for cse332, using no more than ten words.

  4. Make directories for this class. If you have your own directory naming scheme, you can use that instead, but the leaf directories should have the same names as ours (such as lab0).
    mkdir classes mkdir classes/cse332 mkdir classes/cse332/lab0
    If you're not familiar with mkdir, quickly look at the manual page for it with man mkdir. Or, if you prefer, there are graphical tools to help you do all of this.

  5. Make sure you know how to use the following tools:
    1. ls
    2. cd
    3. mkdir
    4. grep
    5. find
    6. diff
    7. wc

  6. Change to your lab0 directory, and write your first C program. Start up an editor (I'd recommend emacs or gedit if you don't have a preference), and create a file called lab0.c with the following contents:
    #include <stdio.h>

    int main() {
      printf("Hello World!\n");
      return 0;
    }
    Yes, this is the "Hello World!" program from class. If you don't know how to use one of the available editors, take a moment to pick one, and find out how it works.

    Compile this program

    gcc -Wall -o lab0 lab0.c
    and run it to make sure it works.
    lab0
    If this doesn't work, then try ./lab0 (we'll talk about this in class).

  7. Look at the resulting executable with the following commands
    1. ls -l
    2. strings
    3. nm
    4. ldd
    Make sure you know what you are looking at in each case (use the manual pages).

  8. Find out what the following command does:
    find . -name "*.txt" | xargs grep "foobar"
    and send a brief explanation to us at     cse332@cec.wustl.edu. Make sure you include your name in the body of this email.

What to Turn In

To get points for this lab, you need to do the following:
  1. Post on the message board, as described above.
  2. Send us email, as described above.
  3. Have done all of the other steps. We won't make you show us that you have done this, but we'll assume that you have. This means that, if you ask a TA for help with these things after this lab has been turned in, you might get a somewhat brief answer.

Grading

This lab will be graded specially. If you do all three parts above, you will get one point. If you do not, you will get zero points. The grades for this lab will be used as a multiplier for all other grades for the rest of this class. We will multiply your grade for every other lab by your grade for this lab.

Yes, we really mean this.

Things to Think About

If you find something particularly interesting while doing this assignment, then feel free to share it with the class on the message board. For example, if you find an excellent editor that will make everyone's life easier, post some details about it.

Among other things, programming computers is about precision. As we progress through the semester, we will give you assignments that are more and more open to interpretation. However, if we tell you to do something a particular way, you should make an effort to do it that way, even if it seems irrelevant. An excellent example of this is the class slogan: We really mean not more than ten words. Slogans, however clever, of more than ten words are wrong answers.

We're also going to assume that you're a grown up and reasonable person. This means that we're sometimes not going to cover all of the interpretations of an assignment question. Try to follow the spirit of the assignment, and if there's any ambiguity, then ask us for clarification. Arguments such as "But, technically, you didn't say that I couldn't comment the code in Klingon" are not likely to receive a warm reception. An excellent example of this is the class slogan: Not more than ten words admits slogans of fewer than 1 word. It also allows the definition of "word" open to interpretation. Zero-word slogans, while pleasing to students of certain Zen schools, aren't really what we're after.

Apart from the pleasing rhetoric of all of this, it does actually have some bearing on programming. Suppose we tell you to read in a line from a file, and that the line will have fewer than ten words on it. Does this include zero as a valid number of words? What are words in this context? If we don't explicitly tell you in the assignment, then you can either ask for clarification, or you can make some (reasonable) assumptions (zero to nine words, words are contiguous sets if characters delimited by the space character), and write them down, so that we know what they are when we come to grade your code.

Page written by Bill Smart.