CSCI 2330
Foundations of Computer Systems
Spring 2021
Instructor: Sean Barker
| 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.
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:
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!
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.
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. 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 turing.bowdoin.edu (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.
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.
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.
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.
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.
//).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 #).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!
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.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:
Makefile with both the default like target and a clean target?like.c program follow the specification above?