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.
Note: everyone with a SUNET ID can access the myth machines. However, you may not have a home directory created for you once you log in. If you encounter an issue when you try to log into myth where it says “could not chdir to home directory”, then this is the reason why. To fix this, submit a HelpSU ticket here (you only need to open the URL and click on the Submit button) to have your home directory set up: Request Home Directory.
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. There are a few different options - first, check out our guide to choosing a text editor for how to decide. Then, follow the instructions below for your text editor.
Click for Guide On Choosing a Text EditorWhile you are not required to use one of the editors here, we strongly recommend using one that is officially supported in CS107, as these are the only one we can provide support for. With these editors, because you are always editing your files on the myth machines via ssh, it means that there is less risk of you losing your work. 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://web.stanford.edu/class/cs107/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]
Vim
Vim is a text editor for editing files on the myth machines. First, we'll set up Vim to do things like display line numbers, standardize indentation, etc. To do this, execute the following command immediately after logging into myth
:
wget https://web.stanford.edu/class/cs107/resources/sample_vimrc -O ~/.vimrc
Vim looks for a special .vimrc
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_vimrc
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/.vimrc’
/afs/ir/users/t/r/troccoli/.v 100%[================================================>] 827 --.-KB/s in 0s
2020-09-14 14:08:35 (46.7 MB/s) - ‘/afs/ir/users/t/r/troccoli/.vimrc’ saved [827/827]
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://web.stanford.edu/class/cs107/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 a sample project, so we can try out the different tools. Make a copy like this:
cp -r /afs/ir/class/cs107/lecture-code/test-project test-project
This makes a copy of the code and puts it in a folder where you currently are called test-project
. As the quarter goes on, you can make copies of lecture code in a similar way, except instead of test-project
it will be e.g. lect5
or lect10
. Go into that folder:
cd test-project
Let's open the args.c
program in a text editor.
Enter something like the following, depending on your text editor of choice:
vim args.c
OR
emacs args.c
When you get the program open, pull up the guide for your text editor of choice, and try out some of the commands to get the hang of your way around.
Click For Emacs Guide Click For Vim GuideWhen 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/test-project$
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.