Graded Assignment 1:
Markdown and Unix shell basics

Deadline

September 13, 2026

Page last modified

October 2, 2026

Overview

This graded assignment consists of creating two Markdown files:

One with notes and reflections on what you learned in the course so far.
Another that includes Unix shell code.

This assignment revolves around the material for weeks 2 and 3; the skills you will practice are Markdown, VS Code, and Unix shell basics.

Directions and grading

Submission expectations

Deadline: Sunday Sep 13^th at 11:59 pm.
Submission: You don’t need to submit anything or notify the instructors: we will look for files, which you’ll create as part of the assignment, in the appropriate location at OSC. (We can also see when the files were last modified.)

Academic integrity

	Use of generative AI tools is not permitted.
	Open-book research for the assignment is permitted.
	Getting help on the assignment is not permitted.
	Collaborating, or completing the assignment with others, is not permitted.
	Copying or reusing previous work is not permitted.
	APA Citations and/or formatting for this assignment are not required.

Rubric

Part A

Criterion	Points
Markdown formatting	2
Content	2

Part B

Criterion	Points
Markdown formatting	1.5
9 numbered steps (0.5 pts each)	4.5

Detailed steps

Setting up

Start a VS Code (Code Server) session at OSC OnDemand, as we did in class this week, selecting the latest available App Code Server version. Make sure the VS Code Working Directory is your personal dir, /fs/ess/PAS3493/people/<user>: either set it when you start the session, or use the Open Folder functionality once in VS Code.
In the VS Code file explorer, create a folder GA1 in your personal dir (/fs/ess/PAS3493/people/<user>/GA1). Both files for this assignment should go in this GA1 folder.
I’d recommend creating your two files directly in the file explorer, each with a .md extension: one for Part A and one for Part B.

General

Both files should be written in the editor within VS Code, and I recommend that you keep a Markdown preview open to the side while you work, so you can check that your Markdown renders as you intended.

Include each of the following syntax elements at least once across your two files combined:

Element	What it should look like
Headers	Several header levels (`#`, `##`, `###`, …), used consistently
Bold text	`bold`
Italic text	`italic` (or `_italic_`)
Inline code	Single backticks, e.g. for file names and for commands mentioned in a sentence
Code blocks	Triple backticks — see Part B
Unordered list	Items starting with `-`
Ordered list	Items starting with `1.`
Hyperlink	`[link text](url)` or `<url>`
Whitespace	Blank lines between elements, and a space after `#`, `-`, and `1.`

Part A: A Markdown document with class notes

Write a summary of what you’ve learned so far in this course. The summary doesn’t need to be comprehensive, and can focus on a few specific elements you thought were interesting or that you’d like to summarize. Make sure to highlight the following (while also including other things you think are important):

One or more things you were excited to learn.
One or more things you are (still) confused about.
In last week’s Project file organization lecture, you were given a set of recommendations about how to organize your project files and document your research. Discuss a few of these recommendations:
- At least one that you think will be really useful.
- At least one that you are not positive about. For example, a recommendation you’re not sure you agree with, or one you think would in practice be hard to implement in your project(s).
Include why you think the recommendation will be useful or not useful in your specific research context.

Part B: A Markdown document with Unix shell exercises

Most of the questions below should be answered with Unix shell code and the output of that code. A few of them instead (or additionally) ask you to explain, predict, or reflect on something.

Copy each of the numbered instructions below into your document, and insert your answers in between — with the code and its output each in its own code block:

Code goes in a code block marked as bash (```bash), so that it gets shell syntax highlighting.
Output goes in a code block with no language specified (just ```).
Every command in your code blocks should have a comment above it (a line starting with #) that briefly says what the command does. It’s a good habit to comment your code.

It does not matter what your working dir is when you start working on this.

A worked example

Assignment questions:

Print your current working directory to screen.
Print the current date and time to screen.

Your answers as part of your Markdown document:

### 1: Print your current working directory to screen

```bash
# Print the path to the dir I am currently in
pwd
```

The output of the command was:

```
/fs/ess/PAS3493/people/jelmer
```

### 2: Print the current date and time to screen

```bash
# Print the current date and time
date
```

The output of the command was:

```
Fri Sep 11 14:30:00 EDT 2026
```

Print the location of your Home directory to screen using a “path shortcut”.
Navigate to your Home directory using an “environment variable”.
Would you say that you just moved to your Home dir using a relative path or using an absolute path? Why?
Navigate from your Home dir to /fs/ess/PAS3493/people/$USER using a relative path.
Click here for some hints
- Read the path shortcuts section and extrapolate from the examples there.
- Start by running pwd in your Home dir and counting how many levels “down” from the root dir / you are — that tells you how many times you’ll need to go back “up”.
Go back to your Home dir, and then move to your personal dir /fs/ess/PAS3493/people/<user> once more — but this time, use an absolute path, and use Tab completion as much as you possibly can instead of typing the path out. Type out your actual user name here rather than using $USER, since the whole point is to let Tab do the typing for you. At which point(s) along the path did pressing Tab not complete anything for you? Explain why not in each case. Also report how many characters of your own user name you had to type before Tab was able to finish it for you.
In the shell, type “ (one double-quote character) and press Enter. What is happening, why is that happening, and how can you get things back to normal?
With the cal command, short-form options can be pasted together: e.g., cal -j -3 can be written as cal -j3. Do you think you can “paste together” long-form (--) options as well? Test your intuition with cal and report back.
Using cal, print a Julian calendar for the month and year in which you were born, and then report the Julian day number of your birthday. (If you’d rather not share your birthday, pick any other month that is meaningful to you, and report which day you picked.)

(Hint: the “Usage” line in the output of cal -h shows how many arguments cal can take, and in which order.)
Do you think you are currently located on a login node or on a compute node at OSC? Write down your answer along with an explanation of why you think so. Then, use the environment variable $HOSTNAME to print the name of the node you are currently working on (we’ll talk more about node names, and what they reveal, later on).

Solutions

Part A doesn’t have a single correct answer, so below are solutions to Part B only. In the example output, paths and node names will differ from yours: <user> stands for your user name.

Part B

1. Print the location of your Home dir using a path shortcut.

The ~ path shortcut points to your Home dir:

# Print the path to my Home dir
echo ~

/users/PAS3493/<user>

The project ID in your path may differ (e.g. PAS0471).
Alternatively, you could have moved to your Home dir with cd ~ and then run pwd.
Note that echo $HOME prints the same path, but $HOME is an environment variable rather than a path shortcut.

2. Navigate to your Home dir using an environment variable.

# Move to my Home dir
cd $HOME

This command doesn’t print any output, though you could run pwd afterwards to confirm where you are. Note that cd ~ and cd without an argument would also take you to your Home dir, but neither uses an environment variable.

3. Relative or absolute path?

This was an absolute path: the shell replaces $HOME by the full path to your Home dir (/users/PAS3493/<user>), which starts with the root dir /. As a result, cd $HOME works regardless of what your working dir is.

4. Navigate from your Home dir to /fs/ess/PAS3493/people/$USER using a relative path.

# Move up three levels to the root dir, then down to my personal dir
cd ../../../fs/ess/PAS3493/people/$USER

Your Home dir /users/PAS3493/<user> is three levels below the root dir /, so you need three .. to get there.
Typing out your user name instead of using $USER is fine too.
Any path starting with / or ~ is not a relative path.

5. Absolute path with Tab completion.

# Go back to my Home dir
cd ~

# Move to my personal dir with an absolute path
cd /fs/ess/PAS3493/people/<user>

Tab can’t complete (all of) a name when multiple entries start with what you have typed so far:

After /fs/ess/P (or /fs/ess/PAS): there are many project dirs starting with PAS, so you need to type (most of) 3493 before Tab can finish it.
Within your user name: other users’ dirs in people may start with the same letter(s) as yours. How many characters you had to type therefore depends on your user name — just enough to distinguish it from all others in /fs/ess/PAS3493/people.

6. Typing “ and pressing Enter.

What: The prompt is replaced by a > on the next line, and nothing is executed.
Why: The command is incomplete: the shell is waiting for the closing ".
How to get out: Press Ctrl+C to get your regular prompt back. (Typing a closing " and pressing Enter also gets you out, but produces an error, since "" is not a valid command.)

7. Pasting together long-form options.

# Try to paste together two long-form options
cal --julian--three

cal: unrecognized option '--julian--three'
Try 'cal --help' for more information.

No, long-form options can’t be pasted together: the result is interpreted as a single (non-existing) long option. Each long option needs its own --, as in cal --julian --three.

8. Julian calendar for the month and year of your birth.

For example, for July 1990:

# Print a Julian calendar for July 1990
cal -j 7 1990

          July 1990
Sun Mon Tue Wed Thu Fri Sat
182 183 184 185 186 187 188
189 190 191 192 193 194 195
196 197 198 199 200 201 202
203 204 205 206 207 208 209
210 211 212

In this example, July 15th, 1990 is day 196.
cal -j july 1990 and cal --julian 7 1990 also work. You can even include the day, as in cal -j 15 7 1990, which will highlight that day in the output.
The order of the arguments matters: the month comes before the year, so cal -j 1990 7 gives an error.

9. Login node or compute node?

You are on a compute node: you started VS Code (Code Server) as an OnDemand Interactive App, and these always run on compute nodes. (Another clue: the node name in your prompt, e.g. p0133, is not a login node name.)
Print the node name:
```
# Print the name of the node I'm working on
echo $HOSTNAME
```
```
p0133.ten.osc.edu
```
Your node name will differ: Pitzer compute node names start with a p followed by digits, whereas login node names look like pitzer-login01.