Getting Started

Written by Chris Gregg, Julie Zelenski and others, with modifications by Nick Troccoli and Lisa Yan

This guide walks you through all the steps to start working on your first program for CS107. You will complete all your programs for CS107 on the myth cluster, which is a set of computers in Gates B08 running Linux (Ubuntu 14) and have various open source tools installed (gcc, gdb, etc.) that we will use. These systems are networked and use a common set of accounts (your SUNet id/password) and have a shared AFS filesystem. There are 30 or so machines in the cluster, individually named myth1, myth2, and so on. No matter which myth you log into, you'll have access to the same installed software, your home directory, and all your files.

Step 1: Install SSH Program

The first step is to set up your own computer to log in to myth remotely. Logging in through a command called ssh will allow you to work on the myth computers in a way that is indistinguishable from being physically in the Gates B08 room. While some version of ssh is available on all kinds of computers, the exact details of this step will be different depending on what kind of computer you have.

Click For Installation Instructions

If you have successfully followed these instructions and logged in to myth, you should see something like this:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 myth57.stanford.edu      
 Ubuntu 20.04 (5.4.0-70-generic)
 8 x Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz, 31.24 GiB RAM, 31.87 GiB swap
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   -> For help with your SUNetID, AFS, or class dirs call 725-HELP, or visit
      http://helpsu.stanford.edu 
   -> For problems with hardware or local/OS software, visit
      http://support.cs.stanford.edu 
   -> With the exception of certain course related mail, the myths cannot
      be used to send or receive email 
   -> The myths are not for CPU-intensive workloads. For alternative
      computers see http://farmshare.stanford.edu 
   -> The new myths are: myth51 - 66 

SUNET@myth57:~$

The "myth57" part may name a different myth (myth1 or myth12, etc). Remember that Gates B08 contains many myth machines. When you ssh to "myth.stanford.edu" as a generic name, you are randomly assigned to one of the myths that is currently most idle (fewest other people trying to use it). This log in greeting message is simply telling you which one you were assigned. You may also ssh to a specific myth by using that myth's name (e.g., ssh troccoli@myth59.stanford.edu), but you usually won't need to do this.

When you log into the myth computers, you are automatically put in your home directory (~), your personal file space on myth. You have access to read, write, and delete files inside your home directory, but you can't read another person's directory unless you have permission.

When you're working via ssh, remember to save early and often. If you get disconnected from ssh while you are working, you will potentially lose any work up to the last time you saved.

When you're ready to log out, you can just close the window, or enter "logout" to log out.

As you're working and entering commands, if your command-line is getting too cluttered, you can use the clear command to clear the currently displayed output. To do a deeper clear, you can use the reset command, which will fully re-initialize the display. The reset command is useful if your input-output somehow get mismatched, but clear will be faster and will work for most use cases.

Step 2: Configure Tools

We will use various tools already installed on the myth machines to work on programs. First, we need to configure them with the correct settings. You only need to do this once.

Text Editor

First, we need to set up a text editor to use for the quarter. We officially support the emacs editor this quarter - it is preinstalled on the myth machines and because you are always editing your files on the myth machines via ssh with this editor, it means there is less risk of you losing your work. While you are not required to use it, it is the only editor we can provide support for in CS107. Learning a Unix-based editor is an essential skill!

Emacs

Emacs is a text editor for editing files on the myth machines. First, we'll set up Emacs to do things like use mouse controls, display line numbers, standardize indentation, etc. To do this, execute the following command immediately after logging into myth:

wget https://cs107.stanford.edu/resources/sample_emacs -O ~/.emacs

Emacs looks for a special .emacs file on your system to know what preferences you would like, and this command downloads our pre-made one and puts it on your system. If you don't do this, you won't be able to use some of the shortcuts and commands highlighted in lecture and the guides. If the command above worked correctly, you should see something like the following outputted to your terminal:

--2020-09-14 14:08:35--  https://cs107.stanford.edu/resources/sample_emacs
Resolving cs107.stanford.edu (cs107.stanford.edu)... 171.67.215.200
Connecting to cs107.stanford.edu (cs107.stanford.edu)|171.67.215.200|:443... connected.
... MORE TEXT HERE...
Saving to: ‘/afs/ir/users/t/r/troccoli/.emacs’

/afs/ir/users/t/r/t 100%[===================>]   1.45K  --.-KB/s    in 0s      

2020-09-14 14:08:35 (61.3 MB/s) - ‘/afs/ir/users/t/r/troccoli/.emacs’ saved [1489/1489]

GDB

GDB is the debugger we'll use in CS107 to debug programs. First, we'll configure it to use the CS107 default preferences; this sets up the debugger to know things like that our work will be in 64-bit systems. To do this, execute the following command immediately after logging into myth:

wget https://cs107.stanford.edu/resources/sample_gdbinit -O ~/.gdbinit

gdb looks for a special .gdbinit file on your system to know what preferences you would like, and this command downloads our pre-made .gdbinit file and puts it on your system. If you don't do this, some behavior may not match guides and examples in CS107.

Step 3: Your First C Program

Each student has their own personal file space on myth. Before working on CS107 programs, it's a good idea to make a folder for your work this quarter, so you know where you can find it. Try making a folder called "CS107" like this:

mkdir CS107

Then go into that folder like this:

cd CS107

Now, let's try making a copy of the lecture 1 code, so we can try out the different tools. Make a copy like this:

cp -r /usr/class/cs107/lecture-code/lect1 lect1

This makes a copy of the code and puts it in a folder where you currently are called lect01. Go into that folder:

cd lect1

Let's open the args.c program in a text editor.

Enter the following:

emacs args.c

When you get the program open, pull up the emacs guide and try out some of the commands to get the hang of your way around.

Click For Emacs Guide

When you're done, put the code back into its original state. Then try quitting the editor.

Now, let's try running the program. When you are in a CS107 project folder that we have provided, type in the make command to compile all the programs. The make command looks in the current directory for a file called Makefile with instructions on how to compile things. We always provide one for you. If all goes well, you should see something like this:

myth$ make
gcc -g3 -O0 -std=gnu99 -Wall $warnflags  args.c  -o args
gcc -g3 -O0 -std=gnu99 -Wall $warnflags  bool_fun.c  -o bool_fun
myth64:~/CS107/lect1$ 

Now, let's run our program. We can run a program in the current directory by entering its name preceded by ./:

./args

And there you have it! You should see something like this:

myth$ ./args
This program received 1 argument(s)
Argument 0: ./args

Try adding more arguments - you can pass in arguments to a program in the terminal when you run it. These arguments are accessible as string parameters to your program's main function:

myth$ ./args hello cs107!
This program received 3 argument(s)
Argument 0: ./args
Argument 1: hello
Argument 2: cs107!

Congratulations - you've just edited and run your own C program. Try going back to args.c to edit the code, compile it again, and run it to see the changes. Remember to always re-compile using make when you make changes! If you don't run make, the changes won't be compiled into your program.