This is not a graded lab assignment, but is a set of things to do to prepare for CS87. You should complete this lab by before class, Thursday Sept. 2.

Goals

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

  • Reminder of the vim editor that you will need to use on some systems.

  • Test out using our class getHub org and git.

  • Review of C programming from CS31.

  • Review pthreads programming from CS31. (important for Lab1 prep).

Unix tools

Here are some useful Unix commands and utilities for manipulating files in our system1. Many of these you know, but some may be new to you. We will learn and use these and others over the course of these semester. For some basics of using our system you can review the CS Department’s Using Unix page (also linked to from the CS Dept Help pages). It includes a nice figure of the file system’s directory structure.

Let’s begin with a reminder about how to remotely log into the cs system.

ssh

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 on 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)

basic 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 cs87 work on our system. For example:

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

$ pwd                             # print working directory
  /home/you/
$ mkdir cs87
$ cd cs87
$ pwd
  /home/you/cs87
$ mkdir Labs
$ mkdir TestCode
$ cd TestCode
$ pwd
  /home/you/cs87/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/cs87/quote ./  # cp: copy a file (to current dir ./)
$ ls
  ... cs87/ ... quote ...

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

$ ls
  ... cs87/ ...

$ cd cs87/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

You may not know all of these commands, but some cat, wc, sort, grep, xargs. In addition, you can incorporate I/O redirection and pipes (|) into command lines to change a process' intput and output to come from files or from other processes. Here are some examples of these commands:

cat quote                  # cat: display file contents 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)

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 differenty 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

Unix Tools Footnotes

  1. On Unix systems everything is a file. This means that every system object has a file interface. Thus, in addtion 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).

Vim Review

We will use some systems this semester where you will need to use the vim editor. You learned the vim editor in CS31, but if it has been awhile since you have used it, you should run through the vimtutor tutorial again (and I encourage you to use it on Lab 1 to get some more practice).

Vim basics

The vi (and vim) editor is available on every Unix system. It is an efficient and lightweight text editor that is easy to use after learning a few basic commands, which you can learn by running though the vimtutor tutorial. vim is particularly useful when working remotely over an ssh connection. It is also has many advanced features and is very configurable through, e.g., the use of a .vimrc file. However, just a few basic commands is enough to get you started.

Vim operates in two modes:

  1. insert mode: keystrokes are interpreted as inserts into the file contents at the point of the cursor.

  2. command or escape mode: keystrokes are interpreted as vim commands, which allow a user to do such things as saving, exiting, searching, or moving around in the file.

To switch from insert mode to command mode, press the ESC key.

There are many ways to switch from command mode to insert mode. One way is to press the i key.

vimtutor

To learn the vim editor, run vimtutor:

  1. ssh into our system and run vimtutor.

  2. After creating a {coursedir} subdirectory in your home directory in the section above, change into this directory with cd:

      $ cd          # go to home directory from current directory
  $ ls          # list (ls) home directory contents
  $ cd {coursedir}     # change directories (cd) to {coursedir} folder
  $ pwd         # print working directory to show full path

    From within your {coursedir} subdirectory run the vim tutorial:

      $  vimtutor     # start the vim tutorial

  3. Go through the sections listed below of vimtutor (the other sections cover more obscure features that are not necessary). It will take about 30 minutes to run through these lessons.

    • All of Lesson 1 (moving around, x, i, A, :wq)

    • Lesson 2.6 (dd)

    • Lesson 2.7 (undo)

    • Lesson 3.1 (p) and 3.2 (r)

    • Lesson 4.1 (G) and 4.2 (searching)

    • Lesson 6.2 (a), 6.3 ( R ), and 6.4 (y and p)

Optionally, you can configure vim in all kinds of ways. You do not need to configure vim in any way to use it on our system. However, you may want to based on foreground and background terminal colors, and set some other options.

In your home directory you can add a configuration file for vim, named .vimrc. On start-up, vim examines this file to set different configuration options for the vim session, including setting a color scheme, and default window size.

To see if you have one already, run ls -a in your home directory to list all your dot files:

ls -a ~/       # ~/ is shorthand for /home/you/

If so, you can open it in vim and edit it like any other file:

cd
vim  .vimrc

If not, it is often easiest to start with someone else’s .vimrc file and then edit what you want. From your home directory, you can copy someone else’s. Here is one you can copy over into your home directory that uses a color scheme that shows up well on dark background windows:

cp ~newhall/.vimrc ./    # you can copy mine over
vim  .vimrc              # then edit it as you like

There are a lot of on-line resources for vim settings.

Some Vim Resources and Links

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 Thursday’s class 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 Thursday.

  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 cs87/Labs/ subdirectory. You can also follow along the more verbose git setup for CS labs (written for CS31 students). Your Lab0 repo can be cloned from the CS87 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 cs87/Labs subdirectory.

    cd ~/cs87/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.

    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. There is no grade for Lab0, but it is a chance for you to practice the steps needed for future labs. 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.

C Programming Review

If it has been awhile since you have programmed in C or C++, you may want to review some C programming from CS31. Here are some things to do:

  • Skim Chapt 1 and 2 of Dive into Systems. Reviewing pointers, strings, and arrays in C will be particularly helpful. Even if you have been programming in C++, it would be good to remind yourself of C strings and arrays (there are neither vector nor string classes in C).

  • Revisit a C program from CS31. One suggestion is the sequential GOL program. Here is a link to one Seq GOL from Spring'21 (this assignment does not include the ParaVis animation part as this was an on-line semester, but your solution likely does).

    NOTE: due to recent system updates, You need to update the Makefile for this CS31 lab assignment to compile and run your gol program. To do this you can copy over a new version of the Makefile that should work from here:

    # cd into your cs31 sequential gol lab repo likely in your cs31/Labs subdirectory
# (NUM is the lab number for the sequential gol lab from when you took cs31):
cd ~/cs31/Labs/LabNUM

# copy the new makefile, Makefile_gol, to your Makefile for this lab:
cp ~newhall/public/cs87/Makefile_gol Makefile

# run make clean and make to rebuild
make clean
make

    You can only run the ParaVis visualization mode when physically logged into a CS lab machine as it is rendered on the machine’s graphics card. The ascii animation mode will work fine when remotely logged in.

Pthreads Review

  • Skim Chapt 14

  • Revisit your pthread’s GOL program from CS31. Here is a link to one from Pthreads GOL from Spring'21 (this assignment does not include the ParaVis animation part as this was an on-line semester, but your solution likely does).

    NOTE: due to recent system updates, You need to update the Makefile for this CS31 lab assignment to compile and run your gol program. Look at the directions for getting a new Makefile from C Programming Review and copy the same one into your cs31 pthreads lab repo.

    NOTE: we will revisit this lab assignment in CS87, so re-familiarizing yourself with the assignment and your solution will be a helpful headstart (you do not need to use the ParaVis part for CS87).

  • Some other pthreads examples from CS31 in-lab pthread practice are available here:

    cp ~newhall/pthread_examples/* .

Handy Resources