CSCI 2330
Foundations of Computer Systems

Bowdoin College
Spring 2021
Instructor: Sean Barker

Lab 0 - Unix Toolbox

Assigned:Monday, February 8
Due Date:Sunday, February 14, 11:59 pm
Collaboration Policy:Level 1
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/Linux environment, using the command line, writing and running programs on remote servers, and version control. 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.

1 - Slack Setup

Questions, discussions, and announcements in this class will all make use of Slack, which is a channel-based messaging platform. Slack will provide a convenient, efficient way to communicate with me, the LAs, your classmates, and your team (for group assignments).

Slack will be used in preference to all other written forms of communication outside of class, including (and especially) email. Once you have Slack set up, do not send me email; send me a direct message (DM) on Slack instead! Similarly, I will post important announcements and information to Slack instead of sending email. Therefore, it is critical that you are configured to receive Slack notifications so you do not miss important information from me. Follow these steps to get set up:

  1. First, watch this 1-minute video to get a quick overview of how Slack works.
  2. Join the CSCI 2330 Slack by going to this course on Blackboard and clicking on "CSCI 2330 Slack Signup" on the landing page. Sign up using your Bowdoin email. Once you have done this (once), you will be able to access the Slack via the regular "CSCI 2330 Slack" link also posted on the Blackboard landing page.
  3. Download the Slack desktop app. While you can also access Slack via the web interface, the desktop app is more seamless and may encourage you to check in more regularly (like a dedicated email client). You can also install the Slack mobile app if desired.
  4. Configure your Slack notifications. As mentioned above, I will use Slack instead of email to make important announcements, so it is critical that you are notified of such announcements. Set your notifications to either "All new messages" or "Direct messages, mentions & keywords". At the bottom of the Notifications preferences, under "When I'm not active on desktop", you may want to check the "Send me email notifications" box, particularly if you might otherwise not be signed into Slack on a regular basis (you can always change these settings later on).
  5. From within Slack, send me a DM so I know that you're set up. I will respond with a code that you will need in your final submission (only at the very end; you don't need to wait for my response before continuing).

The Slack contains four public channels (visible to everyone): general (for announcements and general discussion), inclass (for discussion of material that was covered in-class), labs (for discussion of lab assignments), and random (for anything else off-topic). You can also create your own private channels, which is particularly useful for working in groups. At the moment, creation of new public channels to restricted to admins (i.e., me), but we may alter the public channel lineup later on. If you have a good idea for a new public channel, please let me know!

Now that you are set up in Slack, you are ready to proceed with the rest of the lab and get help along the way as needed!

2 - Unix Crash Course

Go through the Command-Line Unix Crash Course (except for the version control section at the very end). 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.

3 - Accessing the Class Server

The Unix tutorial above had you working on, which is one of Bowdoin's campus-wide Linux machines. However, for the rest of the course, you must use the designated CSCI 2330 server for all lab work. Even if the lab files appear to compile and run on your local machine or one of the other Bowdoin servers, there are subtle differences between operating systems 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)!

The name of the class server is (or if you are on-campus, you can just write turing for short). You have been provided with an account on this server that will allow you to log in and work on your labs. Access to your server account is by SSH key only (no password access). You should have received your keyfiles from me via email (if not, let me know immediately). For instructions on using your key, refer to the relevant section of the Unix tutorial.

Make sure that you are able to login to your account on the class server using your key. If you have trouble, your first stop should be the Unix tutorial. After that, you should ask for help via Slack (or office hours).

From this point on, all lab work in this course should be done on the class server unless otherwise noted. The class server provides a full-fledged Linux environment with all the standard development tools preinstalled (editors, compilers, version control, etc). If there is any software that you would like to use that is not already installed on the server, please let me know.

4 - Version Control with Git

Go through the Git Essential Training Companion Guide, which will guide you through a video series in order to learn how (and why) to use the git version control system. This guide is divided into three parts: (1) the core video series on git, (2) a section on working with GitHub, and (3) a section on using git and GitHub for team collaboration. Skip the collaboration section for now (part 3), since the first few labs will be done individually. We will return to this guide before the first group-optional project.

You should go through this guide even if you already have basic experience with git or GitHub, as you will undoubtedly learn some new things and also make sure that your environment is set up correctly.

Remember to use turing (as opposed to dover) while you are going through this guide. When you are setting up your GitHub account, it is strongly recommended that you configure your GitHub account to use the SSH key that you were provided to access turing. Your key is already installed in the right place on turing, so all you need to do is add the public key to your GitHub account (as detailed in the git guide).

Each lab assignment in this course (including this one) will have a personal git repository accessible only by you and myself in which you will complete and submit your work. At the start of each lab, an invitation link will be posted to Blackboard that will initialize your personal lab repository on GitHub and add any starter files. Once your lab repository is initialized, you can clone it to turing and then begin to work.

5 - Sanity Check

Finally, you will complete a few simple tasks on the class server to check your understanding and account configuration. The main objective here is to make sure that all systems-related issues are dealt with now, as opposed to right before the first 'real' lab is due.

Your task is to write a very (very!) simple C program and a Makefile for the program, then commit your files to your private lab repository and push them to GitHub.

  1. Go to Blackboard and browse to this course. Click the Start Labs menu option on the left, then click the "Begin Lab 0 - Unix Toolbox" link, which will take you to GitHub and walk you through initializing your private lab repository. When this is done, you will be looking at the GitHub page for your new repository.
  2. Clone your new lab repository to the class server as detailed in the GitHub section of the Git guide. Assuming you added your SSH key to your GitHub account as recommended, remember to use the SSH URL to clone rather than the HTTPS URL. If this is setup correctly, git should not ask you for a username and password during the clone. Once you have cloned the repository, cd into the new lab directory. The only starter file in this directory will be a file.
  3. Inside your lab directory, 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.
  4. Write your name and Slack code (from Part 1) in a comment at the top of your program. Comments in C have the same syntax as Java (single-line comments start with //).
  5. Write a Makefile for your C program. Your Makefile should have two targets: the default target (which should be named like) which compiles the program into an executable named like, and a clean target that deletes the compiled files (which in this case is just the like executable). Follow the Makefile example given in the Unix tutorial. Put your name in a comment at the top of your Makefile (comments in a Makefile start with #).
  6. Once your program is finished, you 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 you'd need to run make again before you could run the program again):
    $ make like
    $ ./like systems
    I like systems!
    $ make clean
    $ ./like systems
    -bash: ./like: No such file or directory
    $ make
    $ ./like make
    I like make!
  7. Add your files to your git repository using git add, then commit them using git commit. You will need to specify a commit message describing the changes that you made; at this stage, that message might be something like "added program files". In keeping with best practices, don't add any generated files to the repository (e.g., the like executable). If you want to get fancy, you can add this filename to your .gitignore file so that it won't clutter up your git status output.
  8. Push your commit to GitHub using git push. This step constitutes submitting your lab. You can push your commits to GitHub as often as you want (and doing so regularly is a good idea), but only your final submission prior to the deadline will be considered.

To verify that you submitted your lab files correctly, go back to the GitHub page for your repository. Refresh the page and you should see your new files and changes. If not, go back and check your work.


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

  1. Are all your files pushed to your GitHub repository?
  2. Does your submission include a Makefile with both the default like target and a clean target?
  3. Does your like.c program follow the specification above?
  4. Is your name and Slack code included in a comment at the top of your source code file?