This lab adapts a shell lab due to Eddie Kohler. The high-level design, much of the code, and some of the description below is borrowed from him. A shell parses a command line

Lab 2: Shell
Introduction
In this lab. you will learn how a shell is built. You will also improve (or reinforce) your shell-using skills. You will also gain experience with C programming (you will interact with critical constructs, such as pointers and data structures, as well as standard idioms like linked lists). Along the way, you will use the fork() system call, a lightweight version of which you implemented in the previous lab! There is not much code to write, but there is a lot to absorb; we recommend beginning this lab over the weekend.
This lab adapts a shell lab due to Eddie Kohler. The high-level design, much of the code, and some of the description below is borrowed from him.
A shell parses a command line, and then runs (or executes) that command line (one can also think of GUIs as shells, in which case the “command line” is expressed by the user’s mouse clicks, for example). We’ve given you the skeleton, and nearly all of the parsing code, for a simple but surprisingly functional shell. You will complete the parsing code. You will also fill in the logic for executing the command line: you will implement support for executing commands, I/O redirection, pipes, as well as conditional. sequential, and background execution. You will also implement several internal commands, such as cd. (Puzzle: why does cd have to be built into the shell, when most other commands are executed by exec()ing an existing program?)
You will electronically hand in code and answers (the mechanics are described at the end of the lab).
Please note the following expectations:
Comments. As with the last lab, you are asked to comment every block of code that you write. As a rough guideline, figure that you need a one-sentence comment every four lines or so (but this is rough; feel free to comment larger blocks). In these comments, you must explain the purpose of the code, rather than narrating the instruction that you gave to the computer. Examples of not-good comments are. “assign variable X to variable Y”, “dereference pointer P”, or “the following code is a for loop that iterates over the foo array.” An example of a better comment would be, “We are closing the following file descriptors because [insert reason here]”. To be clear: in the real world, it is terrible style to comment code that is obvious or self-documenting. We are departing from that because, this being a class, we want to make sure that you understand and can explain your code.
Coding style. You will have to pay attention to things like indentation and spacing (which need to be consistent), variable names (which need to be clear and consistent), repeated code (which needs to be avoided), spaghetti code (which needs to not happen), etc. Follow this style guide (also due to Eddie Kohler, adapted from here).
Please note that an otherwise correct solution that is uncommented or whose coding style is problematic will lose points.
Getting started
We recommend doing this lab inside the development platform that you set up in the previous lab (the virtual devbox or the CSIL machines). However, this lab uses standard interfaces and tools, and as a consequence, you can do the lab on OS X or even cygwin on Windows; if you decide to go down that path, note the following: (1) the testing scripts expect to be run on a Linux machine, and will incorrectly report errors for some test cases when they are run on platforms other than Linux, and (2) we will be grading on the standard lab platforms.
From within the development platform that you have chosen (which, in the recommended cases, will be the virtual devbox or the CSIL machines), change to your lab directory, use Git to commit changes you’ve made since handing in lab I (if any), obtain the latest version of the course repository, and create a local branch called 1ab2 based on origin/1ab2 (which is our lab2 branch). The commands are as follows, but you may not need all of them (for example if you are already on the lab1 branch or if git status. indicates that there are no changes to commit):
$ cd /cs170
$ git checkout labl
$ git commit an “here are my leftover changes from lab1” Branch lab2 set up to track remote branch refs/remotes/origin/1ab2.
$ git pull
$ git checkout -b lab2 origin/1ab2
Switched to a new branch “1ab2”
$ cd 1ab2