Lab1

CSC 101, Spring 2011, Lab 1 (Basics) - Common Task

CSC 101, Spring 2011

Lab 1

Objectives

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
- 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

Part 1: The Linux Environment

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, the CSL (14-235).
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. The mouse wasn't yet invented when this stuff was in vogue.
- 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:
```
    csturner@falcon:~ $ mkdir cpe101
    csturner@falcon:~ $ cd cpe101
    csturner@falcon:~/cpe101 $ mkdir lab01
    csturner@falcon:~/cpe101 $ cd lab01
    csturner@falcon:~/cpe101/lab01 $ pwd
    /home/csturner/cpe101/lab01
    csturner@falcon:~/cpe101/lab01 $ 
```
Your first program, your first bug:
- Use an editor (try gedit, some may want to try 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
```
    csturner@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’
    csturner@falcon:~/cpe101/lab01 $ hello
    Hello, world!csturner@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 -Werror -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.
  
  -Werror
  
  Specifies that we want to make all "warnings" into errors so that we'll learn to avoid them.
- Now when I run it, I get this:
```
    csturner@falcon:~/cpe101/lab01 $ gcc -ansi -pedantic -Wall -Werror -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
    csturner@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:
```
    csturner@falcon:~/cpe101/lab01 $ gcc -ansi -pedantic -Wall -o hello2 hello.c
    csturner@falcon:~/cpe101/lab01 $ hello2
    Hello, world!
    csturner@falcon:~/cpe101/lab01 $ 
```

Part 2: Using JGrasp - This part is not mandatory. Do it if you intend to use jGrasp.

The first part of the lab showed you how to create and compile a program from the command line. Some/most of you will prefer to create and compile programs using a more Graphical User Interface. If you wish to do this, follow the instructions here: Using JGrasp.
Many of you will want to install JGrasp on your personal windows machines. If so, follow the instructions here.
We had mentioned in class the use of a simple editor Gedit, you may search on the internet for free downloads, it works on Windows, Mac and Unix machines. It will only help you create your program files, you will compile and run them from the command line, unlike JGrasp above.
To transfer files from your Windows home machine to your vogon account, you can use Secure Shell Client program (for Windows) [5.5 MB] . IF you utilize these programs, remember that I cannot support them as the "target" environment is fixed as vogon.csc.calpoly.edu and is a unix environment. You may write/debug your programs anywhere but must finalize them on vogon for this class.

Part 3: Running interactive programs

Examine the source text for the Number Juggling Program.
Predict the results from executing the program. In this program the user must provide input data. Use your own birthdate and age as input values. Predict the result that the program will produce.
Start jGRASP, create a new editor window, and Copy-and-Paste the text from the listing. Save the program as numberjuggle.c
Compile the program. It should compile without errors.
Execute the program. When the program displays the prompt, provide your input data. Observe the actual output that is produced. Compare the actual output to your predictions. If there is a discrepancy, determine if you calculated wrong or if there is an error in the program.
There is nothing to submit for this part of the lab.

Part 4: Finding Defects

Read the header comments to determine the purpose of the Cable Revenue Program.
The source code has several defects that have been inserted by the instructor. Study the source code and try to identify the mistakes. Note them in your lab notebook.
Start jGRASP, create a new editor window, and Copy-and-Paste the text from the listing. Save the program as cablerevenue.c
Compile the program. Several errors will be reported.
Attempt to fix the errors. In some cases the error message is very obvious and you will see immediately what needs to be corrected. In other cases, the error message is vague or confusing. You might find this list of common error messages helpful. Write each error message and the correction which fixes it in your lab notebook. If you are stuck, you may get assistance from your peers or the instructor.
Execute the program. When the program displays the prompt, provide the sample data of 3 installations and 15 yards of cable. Observe the actual output that is produced. Compare the actual output to your predictions. If there is a discrepancy, determine if you calculated wrong or if there is an error in the program. Resolve the discrepancy and describe it in your lab notebook.
Demo the correctly running program to your instuctor on Vogon.

HANDIN, the way you'll turn in your work to Dr. Turner:

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

Classes