Foundations of Computer Systems
|Assigned:||Friday, August 31|
|Due Date:||Sunday, September 9, 11:59 pm|
|Collaboration Policy:||Level 1 (refer to the official policy for details)|
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.
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.
The Unix tutorial above had you working on Bowdoin's campus-wide Linux machine
dover.bowdoin.edu (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.
The name of the class server is
turing.bowdoin.edu. 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.
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 -- but note that you do need the
sbarker in the directory path):
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 https://repo.bowdoin.edu/svn/sbarker/cs2330/f18/ghopper 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.
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:
lab0which will serve as your lab folder.
like.cthat 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 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.
Makefilefor 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
cleantarget that deletes the compiled files (here, just the
likeexecutable). Follow the Makefile example given in the Unix tutorial. Note that the
-ooption in the compilation command controls what the output executable is named - to make sure the output program is named
like, you will need to change this setting.
$ make build $ ./like systems I like systems! $ make clean $ ./like systems -bash: ./like: No such file or directory $ make $ ./like make I like make!
lab0directory 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).
This lab will not be explicitly graded as such, but your submission will be checked based on the following criteria: