This is not a graded lab assignment, but is a set of things to do to prepare for CS44. You should complete this lab by before lab, Wed Jan. 22.

Goals

  • Remember, and learn, some useful Unix tools. We will learn more as the semester progresses.

  • Reminders about C++ programming: make, gdb, valgrind.

  • Test out using our class getHub org and git.

Unix Practice

Here are some useful Unix commands and utilities for manipulating files1 in our system. Many of these you know, but some may be new to you. We will use these, and others, this semester.

If it has been awhile since you have used the Unix command line, you may want to start with a review of some of the basics of the Unix file system and using Unix. See one of these:

  • Appendix 2: Using Unix, Section 1 of Dive into Systems has a review of the basics of the Unix file system and the Unix command line (later sections in Appendix2 cover some of the other commands presented below).

  • CS Department’s Using Unix page (also linked to from the CS Dept Help pages).

If you are trying these out remotely, you may want to take a look at the ssh (and unix editors) information first.

basic Unix commands

Some basic Unix commands for moving around the file system and manipulating files and directories include: cd, pwd, ls, mkdir, cp, mv, rm, rmdir, chmod. You can remind yourself how these work by setting up a subdirectory structure for cs44 work on our system. For example:

Log into a CS lab machine. To remotely logging in:

$ ssh  you@cslab.swarthmore.edu   # ssh into some CS lab machine

Try out some basic unix commands:

$ pwd                             # print working directory
  /home/you/
$ mkdir cs44
$ cd cs44
$ pwd
  /home/you/cs44
$ mkdir Labs
$ mkdir TestCode
$ cd TestCode
$ pwd
  /home/you/cs44/TestCode

Here are some more things to try using these commands:

$ cd                                # cd: change directories to home dir
$ pwd                               # pwd: print current working directory
  /home/you/
$ cp ~newhall/public/cs44/quote ./  # cp: copy a file (to current dir ./)
$ ls
  ... cs44/ ... quote ...

$ mv quote cs44/TestCode/.          # mv: move a file to different location

$ ls
  ... cs44/ ...

$ cd cs44/TestCode
$ ls
  quote

$ ls -l                            # ls -l : includes other info with each file
-rw-------  1 you users  159 Aug 18 20:46 quote

$ chmod 644 quote                 # chmod: change permissions on file
                                  # rwx options for owner, group, others
                                  # (6:RW to owner, 4:R to group, 4:R to others)
$ ls -l
-rw-r--r--  1 newhall users  159 Aug 18 20:46 quote

$ cp quote quote_copy

$ touch file1                     # touch: create an empty file
$ ls
  file1 quote quote_copy
$ rm quote_copy                   # rm: remove a file
$ ls
  file1 quote

$ mkdir oops
$ ls
$ rmdir oops                     # rmdir: remove a directory
$ rm file1
$ ls

more file manipulation commands

Some other commonly used commands are cat, wc, sort, echo, grep, and xargs. Here are some examples of their use (Appendix 2 has more details):

cat quote            # cat: display contents of quote file to stdout
wc quote             # wc: word count of file (Q: what do 3 values count?)
sort quote           # sort: lines of file
echo "hello there"   # echo: print message to stdout
grep teach quote     # grep: search for pattern (teach) in a file (quote)

In addition, you can incorporate I/O redirection and pipes (|) into command lines to change a process' input and output to come from files or from other processes (and here is more information on I/O redirection and pipes).

With each process are 3 files: stdin, stdout, and stderr. stdin is where the process' input is read from, and stdout and stderr is where the process' output and error output is written to. By default stdin is the keyboard and stdout and stderr are the terminal. However, you can change where a program’s stdin, stdout, and stderr to come from different files using I/O redirection. Each has a file descriptor (stdin:0, stdout:1, stderr:2), and it may be used to specify which of these is being redirected in the notation: < redirect stdin; > or 1> redirect stdout; 2> redirect stderr. You can also feed the output of one process or builtin command into the stdin of another using pipes (|).

Here are a few examples:

cat quote > another_one       # >: redirect stdout to a file
                              #    (redirect output of cat to another_one)
wc another_one

cat blah
cat blah 2> error_out         # 2>: redirect stderr to a file

echo "Again:" >> another_one  # >>: append echo's output to file another_one
cat quote >> another_one
wc another_one

sort quote >> another_one
cat another_one
ls -l
grep teach quote
grep teach another_one

grep teach < quote    # <: redirect stdin from a file (grep's stdin from quote)

cat quote
cat quote | grep teach     # pipe (|): stdout of cat into stdin of grep

cat another_one | wc          # pipe stdout of cat into stdin of wc

cat another_one | wc | grep 3 # pipe stdout of cat into stdin of wc
                              # and stdout of wc into stdin of grep
ls
ls | wc           # Q: what do you think wc is counting in this command?
ls | xargs wc     # xargs: execute a command (wc) on values passed in on stdin
                  # (run wc on each of the files listed by ls)

Most Unix commands are very configurable through command line arguments (e.g., ls -la lists more files and lists them differently that ls). You can find out more information by reading their man pages and looking at some examples on-line, and then trying them out on some practice files and directories.

man

To find out more information about Unix command and library functions use man to read manual pages. For example, to see the man page for ls and all its command line options:

man ls

apropos is helpful for finding commands or library functions related to some functionality (if you can’t remember the name of the command of function).

Here is some more information about man and apropos

ssh

We encourage you and your lab partner to work together in the CS labs. However, you can also remotely log into CS lab machines. ssh is used to remotely log into one CS lab machine from another on our system, or to remotely log into a CS lab machine from your home machine running Linus or MacOS. On a Windows machine you need to install and use something like putty to remotely connect via ssh (see remote access for more details).

To connect to a CS machine from your home machine or from a CS lab machine to another run ssh from a shell prompt:

$ ssh  you@cslab.swarthmore.edu   # ssh into some CS lab machine

$ ssh  you@carrot.swarthmore.edu  # ssh into a specific CS lab machine (carrot)

When remotely logged in, we recommend logging into two terminals: one for compiling and running; and the other for editing. We also encourage you to use a Unix editor like vim (or emacs) when remotely connected (or just in general).

Unix editors

You are welcome to use any editor program you’d like in this class.

However, the Unix editors vim (or emacs) are particularly useful for remote editing, and we ecourage their use. They are much more resource efficient than vscode, making them a greener option, and in general they will have better reponse rates over remote connections. In addition, Vim (and usually emacs too) is available on every Unix system, so it is good to learn---even if you use vscode as your primary editor at Swarthmore, you may not have vscode at a job or in graduate school. Finally, vscode and git can interact strangely, so if you use vscode, I strongly encourage you to save and exit before doing a git pull.

Here is some information about learning Vim or Emacs (you do not need to learn both, and we recommend Vim if you don’t know either):

Unix Tools Footnotes

  1. On Unix systems everything is a file. This means that every system object has a file interface. Thus, in addition to regular files and directories that you think of as being part of the file system, other objects like keyboards, disks, and processes, and OS exported policies and runtime state, can be accessed through a file interface (e.g., look at files in /dev, /proc, /sys).

Git Practice

We will be using Swarthmore’s GitHub Enterprise to get and submit lab assignments. You have used git in previous CS courses, but if it has been awhile, you may want to read over some documentation. You likely will not need to create and add ssh keys, but you may need to do so if you have don’t remember your passcode.

Below are some steps to follow to try cloning your Lab0 repo to test out git and github. Please try this before Wednesday’s lab so if you have problems or something is not set up correctly, I can help you or fix it before we start the Lab1 assignment on Wednesday.

  1. Read the Git Overview and Setup and Configuration sections of the Git Help page, and then try cloning a copy of the Lab0 repo in your cs44/Labs/ subdirectory. You can also follow along the more verbose Using git for CS44 labs. Your Lab0 repo can be cloned from the CS44 GitHub organization for our class.

  2. All Swarthmore students should have a Swarthmore GitHub account connected to your ITS username and password. You can login to do some of the initial setup steps at

  3. Possible Add SSH keys (you may not need to as you have set this up from past classes, but if you cannot git clone then try this):

    Follow the ssh-keys and config steps link from the Setup and Configuration directions for information on how to generate ssh keys and upload your public ssh key (generated from your CS account) that is necessary to clone repos on our system. Make sure you are logged into the CS network via ssh before creating your keys. It is possible, particularly on a Mac to create keys, just for your home machine/laptop, but that is not the goal here. Add your public key as a new SSH key on your Swarthmore GHE key settings.

  4. Clone your Lab0 repo in cs44/Labs subdirectory.

    cd ~/cs44/Labs
git clone {gitssh}/Lab0-yourUserID.git
cd Lab0-yourUserID
ls

  5. Submit Changes. If you successfully cloned the Lab0 repo, open the README.adoc file in vim and follow the directions for editing the file and then committing and pushing your changes using git.

    vim README.adoc       # edit README.adoc in vim
git add README.adoc   # make this file part of next commit
git commit -m "updated readme documentation" # locally commit changes w/message
git push              # send changes to GitHub

    You will need to remember to add, commit, and push each time you want to submit something for a grade. The push command sends files that have been added and committed to the GitHub servers, which is where graders and staff have shared access to your files. You can log into GitHub and view your repo contents to check your if changes are there. If they are on GitHub, you did the steps correctly.

There is no grade for Lab0, but it is a chance for you to practice the steps needed for future labs.

EdStem Practice

Try out the EdStem page for this class by posting a response to my Lab 0 Question.

C++ Programming Tools

Take a quick look at Wed in-lab example for week 1 for some reminders about C++ programming, compiling programs, and debugging tools (gdb, valgrind).

We will briefly review these tools during lab the first week of class, so you do not need to run through the in-lab exercises. However, if it has been awhile since you have programmed in C++ (or C) we strongly recommend that you try compiling and running these examples, and try out the gdb and valgrind examples before the first lab meeting of class. We also encourage you to review some of your lab assignment code from CS35 (or your CS31 C lab assignment code if you placed out of CS35) to review some C++ syntax.

In Handy Resources there are links to some C++ programming references that are helpful if you need a review.

Handy Resources