CSCI 2330
Foundations of Computer Systems

Bowdoin College
Spring 2018
Instructor: Sean Barker

Lab 0 - Unix Warmup

Assigned:Monday, January 22
Due Date:Thursday, February 1, 11:59 pm
Collaboration Policy:Level 1 (refer to the official policy for details)
Group Policy:Individual

This lab is designed to introduce and familiarize you with many of the tools that we will be using throughout the semester. Most significantly, this lab will teach you the basics of working in a Unix environment, using the command line, and writing and running programs on remote servers. Getting a handle on your working environment early on will save you lots of time in the long run and let you focus on the actual course material of the later labs.

Part 1 - Unix Crash Course

Go through the Command-Line Unix Crash Course. If you have never worked in a command-line environment before, this tutorial may take you some time. If you have some Unix background, you may already have seen most of this material (but you should still at least skim the tutorial to make sure).

A few parts of the tutorial involve short snippets of C code. Don't worry if you've never written any C code before; focus on the conceptual ideas being illustrated (e.g., the process of compilation and the use of command line arguments) and don't get bogged down by the details of C at this point. We'll dive into the details of C later in the semester!

There is nothing to submit for this part.

Part 2 - CSCI 2330 Environment Setup

The Unix tutorial above had you working on Bowdoin's campus-wide Linux machine (or, if you're on a Mac or a Linux machine yourself, you may have done the tutorial on your own local machine). However, for the rest of the course, you must use the designated CSCI 2330 server for all labs. Even if the lab files appear to compile and run on your local machine, there are subtle differences between Linux and macOS (and between different version of Linux) that may cause hard-to-debug problems. Avoid these problems by always working on the class server (which is also the server that will be used to evaluate your programs)!

In this second part, you will configure your account on the class server and then complete a few simple tasks on the server to check your understanding. The main objective here is to make sure all systems issues are resolved now, and not right before the first 'real' lab is due.

If you are unsure how to accomplish any of the tasks in this part, your first stop should be the Unix tutorial above. After that, you should consult Piazza, the instructor, TAs, etc.

Accessing the CSCI 2330 server

The name of the class server is You have been provided an account on this server that will allow you to log in and work on your labs.

Access to the server is by keypair, which you should have received via email from me. For instructions on using your keypair, refer to the relevant section of the Unix tutorial.

The server provides a full-fledged Linux environment with all the standard development tools (editors, compilers, version control, etc) preinstalled. If there is any software that you would like to use that is not already installed on the server, please email me.

Checking out your SVN directory

We will use Subversion for storing and submitting all labs. Using Subversion has several advantages: (1) your work will be backed up in the Subversion repository, (2) it will be easy to work in groups later on, and (3) it provides an easy way for me to access your lab files, both before and after you have officially 'submitted'.

Each of you has a dedicated directory on Bowdoin's Subversion server for your work in this class, which you and only you can access. Your personal directory is at the following directory (again using your actual username instead of username):

Log in to the class server, then checkout your SVN directory. You can give svn checkout a second argument to specify the name to give the checked-out repository. For example, if your user ID is ghopper, you might run this:

svn checkout my-systems-repo

The above command would create a new directory named my-systems-repo (which is the checked-out repository) in the current directory (you can give it any name you wish). Initially, there are no files within your SVN directory, so your checked-out repository will have no files.

Remember that checking-out the directory is generally a one-time step. Once you have a checked-out (i.e., local) copy of the repository sitting in your home directory on the server, you will work on all of your labs within that directory. You should not need to check-out the directory again.

Part 3 - Sanity Check

Your last task is to write a very (very!) simple C program, a Makefile for this program, and then check your files into your SVN directory. First, cd into your checked-out SVN directory, then do the following:

  1. Create a directory called lab0 which will serve as your lab folder.
  2. Within your new lab folder, write a program called like.c that simply prints the message "I like [xyz]!" where [xyz] is the first command line argument. If the program is not given any command line arguments, or is given more than one, it should instead print "What do I like?". Here are a few examples, assuming the executable compiled from like.c is named like:
    $ ./like pizza
    I like pizza!
    $ ./like Linux
    I like Linux!
    $ ./like
    What do I like?
    $ ./like Linux pizza
    What do I like?
    If you've never written a C program before, just use the example in the Unix tutorial as a starting template and modify that -- you don't need any further knowledge of C to complete this part. Your name should be included in a comment at the top of your program.
  3. Write a Makefile for your C program. Your Makefile should have two targets: the default target (which you should call build) which compiles the program into an executable named like, and a clean target that deletes the compiled files (here, just the like executable). Follow the Makefile example given in the Unix tutorial.
  4. Once your program is finished, I should be able to run the following set of commands from your lab directory to compile your program, run it, and then clean up (at which point I'd need to run make again before I could run the program again):
    $ make build
    $ ./like systems
    I like systems!
    $ make clean
    $ ./like systems
    -bash: ./like: No such file or directory
    $ make
    $ ./like make
    I like make!
  5. Add your entire lab0 directory to the SVN repository using svn add, then commit your files using svn commit. This constitutes 'submitting' your lab. Although you may also make changes later on, the most recently committed files in your SVN directory will be considered your submission. Note that you need not check in your compiled executable to SVN (since this can be immediately regenerated from the source code using the Makefile).

If you want to verify that you committed your lab files correctly, go to some directory outside of your checked-out SVN directory, and check out a fresh copy of the repository (i.e., run the svn checkout command again, but give it some other target name, like my-repo-check). If you committed your lab files correctly in the previous steps, then when you checkout the directory again, you should see a copy of your lab files in this new checked-out directory.

Once you've finished verifying that your check-in was successful, delete the second checked-out directory (my-repo-check in this example) to prevent having multiple checked-out directories (which could be confusing if you accidentally use both of them).


While this lab is only a warmup, your submission will be checked based on the following criteria:

  1. Does your program follow the specification above?
  2. Does your program include a Makefile with both the default target and a clean target?
  3. Are all your files checked into your Subversion directory in the lab0 subdirectory?