CSC 101, Fall 2007

Lab 1 (Basics) - Common Task

Updates and Changes

None so far.

Objectives

This is the common part of the lab, shared among all instructors. Here, our goals are:

To ensure you know how to use the basic tools we'll be needing in the rest of the course:
- Basic command-line operation
- Basic navigation in Linux
- Browsing your Kindly Instructor's class home page.
- Downloading to a Linux directory.
- Basic Linux commands
- Program ssh(1) - Secure Shell
- Program handin(1) for handing in homework.

Aside

This is commentary that is not part of the assignment, but is intended to help you understand some of the ways we write about things.

Did that program name ssh(1) look a little odd to you? That number in parens is a Unix and Linux idiom you should get used to. It signifies that the item ssh is listed in a "man page", in the section whose number appears in parens.
In this case, it's a shell command, so it appears in section 1.
This tells you that the command "man ssh" is likely to give you a lot of information about this program. When you get to Linux, try it.
Be warned that man pages, while useful, are written by and for experts. They're a bit daunting at first, but you can get used to them, and it's a lot better than trying to carry a library in your backpack.

Overview

You will download a file, modify it, and submit it as homework.
The first day of each term tends to be chaotic in the labs, particularly the first lab of the day. This year in particular, the computing environment is a work in progress. Accordingly, I expect that some of you will encounter difficulties that are not your fault. Do not worry about it; just try to get the problems fixed.
This is just about the only time in the course where being here and putting in the effort is all that's required, rather than specific results.
That said, I expect you to overcome the difficulties, and accomplish all these tasks -- I just know it will take some folks longer than others regardless of skills.

The Rules

There are no rules for this one really, except that I want you to do your own web navigating and your own typing. The point is to learn what to type, and to practice doing it.

Lab Requirements

Get connected:

Find a lab machine.
Log in Linux. This is is the main environment we will be using, so it's top priority to get familiar with it. In case of trouble:

Try again. Be careful about capitalization.
See the lab staff in or around the open lab downstairs (14-235).

Locate and start the Firefox browser. It should be a reddish icon in the bar at the top of your screen. If you look real close, it's a fox curled up around the Earth.

Go to my.calpoly.edu and do the following:
- login
- In the "Blackboard Access" area, click on the blackboard link for your lecture section of CPE 101.
- Click on the "Discussion Board" option in the lefthand menu.
- Make a post in the Student Discussion forum.

Get started with the command line:

Browse Prof O'Gorman's web page on basic Unix commands. Make a note of this location.
Start a command shell. As an icon, it looks like a computer screen. In the menus, it's probably called "Terminal". It opens a window where you type commands for immediate execution. Look, ma! No mouse!
Note that the first thing you'll see is an odd bit of text, followed by a blinking cursor. You may be familiar with the cursor, but what's that bit of text? Note that it has your username in it, and the other stuff tells you what machine and what directory you're using right now. Later when you're using more than one machine and moving around in directories, this is going to be very handy. It's called a prompt.
The commands you type will go right after the prompt.
Create (look up "mkdir" in that list of Unix commands) a directory cpe101 for all the stuff for this course.
Make cpe101 your current directory ("cd").
Create a directory lab01 just for this lab.

Have the system report your current directory ("pwd"). It should start with "/home/" and end with "/cpe101/lab01". When I do these steps it looks like this (your colors and other details may vary:

    kogorman@falcon:~ $ mkdir cpe101
    kogorman@falcon:~ $ cd cpe101
    kogorman@falcon:~/cpe101 $ mkdir lab01
    kogorman@falcon:~/cpe101 $ cd lab01
    kogorman@falcon:~/cpe101/lab01 $ pwd
    /home/kogorman/cpe101/lab01
    kogorman@falcon:~/cpe101/lab01 $

Your first program, your first bug:

Use an editor (probably gvim) to write and save the following C program. Call it "hello.c". Be very careful about that name (and all names when you're programming). Capitalization counts. Spelling counts. Everything counts.
```
    	main()
    	{
    	    printf("Hello, world!");
    	}
```
Compile your code with the command: "gcc -o hello hello.c"
You will see a warning message. That is bad. That would cost you in your assignments, so we'll have to fix it up before we're done.

For now, run your program with the command "hello", or if that does not work, use "./hello" and it should print out a little message. If none of this is working right, get help. When I run it, I get

    kogorman@falcon:~/cpe101/lab01 $ gcc -o hello hello.c
    hello.c: In function `main':
    hello.c:3: warning: incompatible implicit declaration of built-in function ‘printf’
    kogorman@falcon:~/cpe101/lab01 $ hello
    Hello, world!kogorman@falcon:~/cpe101/lab01 $

That's pretty awful. Not only do I get a warning, but the output messes up the prompt, which should always start in the left margin. That's a bug. Let's fix the output bug first. You do that by making your program's output return to the left margin before it quits. That is accomplished by an escape sequence which introduces a formatting character into the output. There are several of these escape sequences, but the one that you'll be using all the time is called newline and looks like this: "\n". It works only inside of quotes, so change that message to look like this: "Hello, world!\n".
Edit the program. Compile it again. Run it again. Now the prompt should appear as it should: on a line of its own.

Lessons to learn:

What just happened is the cycle of programming (short version) that you will encounter over and over again. Edit - compile - run - bug! Bugs are a fact of every programmer's life. There's always something you didn't know, or didn't think about, or that is not as you expected. Programmers spend their lives in this cycle, (a few other things, like design and re-design come in as well), not just writing perfect programs the first time. In fact, the perfect program is extremely rare.
That compiling step probably looks pretty weird. Why is "hello" in there twice, for instance? Let's take it piece by piece.

gcc: The first thing on a command line is a command. GCC is the compiler we will use throughout this course, and the command is "gcc". The compiler turns our C code into something the machine can execute. Naturally enough, we call those executables.
-o hello: The "-o" part is a switch which tells the compiler we're about to give a name for the executable. The "hello" part is that name, and because we created an executable named "hello", later on we'll be able to use "hello" or "./hello" as a command to run our program.
hello.c: This part is not part of a switch, and tells the compiler the name of the file that contains our program.

So what about that warning?

You might expect that since the program ran and did what we wanted, that we're done with it. You'd be wrong, I'm afraid. For one thing, we will never again compile a program with exactly that command line. This warning turned out to not matter, but most of them are actually things that should only very rarely used, and then only by experts.
When we grade your programs, we are going to penalize warnings. Most of the time, the warnings will actually turn out to be bugs, so you ought to treat them seriously anyway, and fix them before you even try to run your program.
We have a couple of difficulties fixing this one. For one thing, the warning message is pretty cryptic at this point, right? You're wondering what the words "declaration" and "function" mean here. The problem is that C is a language for experts, engineered to communicate with experts. You're not there yet. Accordingly, your Kindly Instructor expects to spend a lot of time at first turning these horrible error messages into English for you.
This message is telling us that the compiler is not sure that we are using the printf function correctly. In this case, it turns out that we are, but it is better if we tell the compiler the details. We do that by telling the compiler about another file that has all those details already, and we add a line to the top of the progran:
```
    #include <stdio.h>
```
This is a header file, which we'll explain later, so it ends in an ".h" instead of a ".c". Just about all programs have this one somewhere. It defines all of the most common things programmers use to get data or messages into or out of their programs. This is generally referred to as input/output or just "I/O".
Re-enter the cycle of programming and edit your program to add this line. Compile it. Run it. It should look clean, and run just as it did before.

Are we there yet? Sadly, no.

It turns out this program is not yet acceptable. There are two other problems to fix, even though it seems to run fine. Running fine is kind of accidental in this case, and happens because we're not expecting much from the program. We missed it because we still didn't use the correct command line. We've got one more change to make to the command, and two changes to make to the program.
We expose the problem by using the command-line that we'll be using with minor variations throughout the course.
```
        gcc -ansi -pedantic -Wall -o hello hello.c
```
Here's what's going on:

-ansi

Specifies the language standard that our program adheres to.

-pedantic

Specifies that we really mean it, and want to know if we do something non-standard.

-Wall

Specifies that we want more than just the most obvious warnings, but want warnings about all the mistakes that the compiler can catch for us.

Now when I run it, I get this:

    kogorman@falcon:~/cpe101/lab01 $ gcc -ansi -pedantic -Wall -o hello hello.c
    hello.c:3: warning: return type defaults to int
    hello.c: In function main
    hello.c:5: warning: control reaches end of non-void function
    kogorman@falcon:~/cpe101/lab01 $

We're going to fix these without explaining the details. Suffice it to say that there are expectations of a program that this one does not meet. We're going to see a lot of "main" programs, and they're all going to have these issues. You just have to learn it for now, and let us explain it later when it will make more sense.
First, we have to put the word "int" before the word "main", either on the same line or on a new line above. You instructor may have a preference about this, so pay attention to what is required.
Second, we have to add a line after the printf and before that curly brace ("}"). It should contain
```
    	return 0;
    	    
```
Once more into the cycle. Re-edit. Re-compile. Re-run. If you pay attention to the details, the program should come out like this:
```
    	#include <stdio.h>
        int
        main()
        {
            printf("Hello, world!\n");
            return 0;
        }
```

When I try it, it looks like this:

    kogorman@falcon:~/cpe101/lab01 $ gcc -ansi -pedantic -Wall -o hello2 hello.c
    kogorman@falcon:~/cpe101/lab01 $ hello2
    Hello, world!
    kogorman@falcon:~/cpe101/lab01 $

Follow the instructions below to hand in hello.c to the lab01 directory.
Demonstrate your progress.

Call your Kindly Instructor over when you're ready. That means that your current directory is your cpe101/lab01, and your program is ready to run.

Handin

Submit your hello.c using handin. To do this, you must do the following steps.