CSCI 2330
Foundations of Computer Systems

Bowdoin College
Spring 2024
Instructor: Sean Barker

Lab 0 - Unix Toolbox

Release Date:Monday, January 22.
Acceptance Deadline:Tuesday, January 30, 11:59 pm (same as due date for Lab 0 only).
Due Date:Tuesday, January 30, 11:59 pm.
Collaboration Policy:Level 1
Group Policy:Individual

This introductory 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.

0 - It's in the Syllabus

First, read the class syllabus so that you are aware of important course policies. If you have questions or need clarifications on anything in the syllabus, please let me know! Going forward, I will assume that everyone has read and is familiar with all policies and procedures detailed in the syllabus.

Somewhere within the syllabus is a code (unique to you) that you'll need to submit in the next part of the lab. Make a note of this code!

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 using the invitation link that was sent to your Bowdoin email. If you haven't received an invitation email, let me know. Once you have joined, you will be able to access the Slack using the regular CSCI 2330 Slack link (which is also posted to Canvas).
  3. Download the Slack desktop app. While you can also access Slack via the web interface, the desktop app is more seamless and will make it easier to stay up-to-date. You can also install the Slack app on your devices for easy mobile access.
  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 containing your code from the course syllabus so I know that you're set up.

The Slack contains five public channels (visible to everyone): assignments (for discussion of lab assignments), general (for announcements and general discussion), inclass (for discussion of in-class material), random (for anything off-topic), and scheduling (for the regular LA and office hours schedules and any temporary schedule changes). You can also create (private) DM threads with multiple participants. To post anonymously in a channel, just type your message like so: /anonymous This is an anonymous message (but note that you cannot reply anonymously inside a message thread). Messages can also be edited or deleted after posting.

Now that you are set up in Slack, you should rarely, if ever, need to send me email! Just DM me instead.

One Slack caveat to be aware of: due to how Slack operates free workspaces, messages are automatically archived (and not easily retrieved) 90 days after being sent. As a result, the class Slack should not be used for any long-term storage (and note that 90 days is a bit less than the length of the semester, so messages sent during the first few weeks of the semester will no longer be accessible prior to the end of the semester).

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 dover.bowdoin.edu, 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, which is hopper.bowdoin.edu (or just hopper for short if you're on campus). Even if the lab files appear to compile and run on your local machine or one of the other Bowdoin servers (like dover), 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)!

You have been provided with an account on hopper 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 hopper 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 and I can probably install it.

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 hopper (as opposed to dover) while you are going through this guide. When you are setting up your GitHub account, you should configure your GitHub account to use the SSH key that you were provided to access hopper. Your key is already installed in the right place on hopper, 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 Slack 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 hopper 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 simple C program and a Makefile for the program, then commit your files to your private lab repository and push them to GitHub.

  1. A private invitation link will be posted to the Slack for the purpose of initializing your private lab repository on GitHub. Click this link, which will take you to GitHub and walk you through the setup process. 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 set up 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 README.md 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 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.
  9. Verify that you submitted your lab files correctly by browsing to your lab repository on GitHub (if you are already there, just refresh the page). You should see your newly added files listed in your repository inside your browser window. If you don't see them there, one of the earlier steps wasn't completed successfully, so go back and check your work (and ask if you need help).

Evaluation

This lab will be marked pass/fail only based on the following criteria:

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

The most common mistake students make is forgetting to commit and push to GitHub (or doing so improperly). Be sure to verify that you did so correctly via the GitHub website as described above.