You are expected to understand this. CS 111 Operating Systems Principles, Winter 2011
You are here: CS111: [[lab1a]]

Lab 1a: CS 111, Winter 2011

Assigned Monday, January 3
"Due" Monday, January 10 at 11:59pm
Download skeleton code from CourseWeb


Lab 1 is divided into two parts. In this first part of the lab, you will be writing the command line parsing portion of an operating system shell. The shell will be completed in the next part of the lab, and will include support for I/O redirection, pipes, and conditional, sequential, and background execution.

Don't know what a shell is, or not too familiar with the Linux/Unix shell? Check out this tutorial, which is a bit wordy but not bad.

When you type a command into a shell, the first thing that the shell does is break the command into individual words (also called "tokens"). These tokens can be command names, command arguments, or special shell tokens. For instance, the command

ls -l "foo bar" > zot

consists of five tokens: "ls", "-l", "foo bar" (the quotes are not part of the token), ">", and "zot". You will need to fill in a function that performs this step one token at a time. More information is available in the lab files.

The next step, at least in the shell for this lab, is to parse the sequence of tokens into individual commands. Since multiple commands may be listed on the same command line, separated by ;, &, |, &&, ||, (, or ), you will have to detect these tokens and stop reading the current command. We have provided a function which calls the command parser repeatedly until there are no more commands, and connects the resulting command structures together so they can be processed in the second part of the lab. You will need to fill in some details in this function to store the command separator used to separate the commands into the command structure.

Lab environment

To do this lab, you will probably want to use a Linux machine. Other Unix variants like Mac OS X will probably also work.

There are many resources you can use to become more familiar with Linux in general and the tools and methods you will be using to complete this lab. The Linux User Group ("LUG," is located in 3820 Boelter Hall, and members are often available in the lounge to answer Linux-related questions. The internet and the class mailing list are also good resources, and of course the TAs for the course can be reached via email and during office hours. You might also try using the system manual pages, which are available by running "man topic" where topic is the name of the function or program you are interested in.

Lab materials

The skeleton code you will get for the first part of the lab consists of six files: cmdline.c, cmdline.h, main-a.c, Makefile,, and answers.txt. answers.txt is a handin template file to contain your name(s), student ID(s), and other information about your lab. It is critical that you fill in this file in order to get credit for the lab. is a program that runs your cmdline through several example test cases and reports its findings. For failed tests it will report the input and expected and actual outputs.

A "Makefile" is a file containing rules for how to compile source code; it is read by the make utility. When you run make, it scans the makefile for the default "target" (i.e. desired output file) and, if any of the source files needed to build that target are newer than the target itself, it compiles them to regenerate the target file. You may also specify a target name on the command line, and then make will build that target instead. In the first part of the lab, the default target is the cmdline program, so to compile your source code you only have to run make with no arguments when in the lab1a directory.

The file you will actually get is lab1a.tar.gz. This is an archive file (much like a .zip file) and to extract it, you should run tar xvzf lab1a.tar.gz in the directory containing the archive. This will create a directory lab1a containing the six files mentioned above.

Text editors

To edit the source code, you can use a variety of editors. Just about all Unix machines (including Linux machines) come with two popular editors: vi and emacs. There are several variants of each, for instance the much-improved vim editor and its graphical companion gvim. Another popular (and simpler) editor installed on the SEAS lab machines is nano. To start these text editors, you normally type the editor's name at a command prompt, followed by the name of the file you want to edit. The SEAS lab machines also have a simple and graphical editor called gedit installed; gedit can be started from the command line or by clicking on its icon in the pop-up "start" menu.

As a further option, there are IDE ("integrated development environment," like MS Visual Studio) packages available for Linux. One common Linux IDE is called KDevelop, and it is installed on most of the lab machines. You can install it on your own machine, if you have a Linux machine (which the LUG will be happy to help install at the "Installfest").


After compiling your program, you can run it by typing "./cmdline" at the command prompt. (For the curious: why do you have to type the ./? Hint: research the PATH environment variable.) It will display its prompt, cs111_winter11$. Now you can type commands to it, just like the normal system shell you used to start it. After each command you type (and after you press enter), it will display some output indicating what it parsed. To quit your program, you can press control-C to kill it.

We have also provided an automatic tester that will run your command line parser through its paces. Run the tester on your code by running ./ at the command prompt. (You can also run make grade.) There are 46 tests in all. You can figure out what the tester expects by looking at ./ (it will also tell you what it expects for every failed test).

Extra credit

Enhanced token parsing

Recognize shell special tokens even when they are not surrounded by spaces. For instance, parse "ls;echo" as three tokens, "ls", ";", and "echo". (The "2>" special token must be preceded by a space, however; for example, parse "ab2>x" as "ab2", ">", and "x", not "ab", "2>", and "x".)


Real shells interpret backslashes as escape characters inside double quotes. Thus, the command line

echo "\""

will print a double-quote character, like so:


For normal credit, we won't test how you handle backslashes, so it is OK if you treat echo "\"" as an error. For extra credit, implement correct backslash handling, as described in the bash manual page.

Feel free to contact us if you have an idea for additional extra credit.


When you are finished, make sure you fill in the answers.txt file (see the instructions at the top of the file), and run "make tarball" which will generate a file lab1a-yourusername.tar.gz inside the lab1a directory. Upload this file to CourseWeb using a web browser to turn in the project.

We will check your work on Lab 1a, but we will not grade this part of the project separately. All of Lab 1, including additional work we will hand out at the end of this week, is due on January 21. (So, you may still make changes to cmdline.c after Lab 1a is due.) Take this opportunity to get started EARLY on learning the Linux lab, Unix command-line tools, and so forth.

Good luck!

lab1a.txt · Last modified: 2011/01/03 23:24 by kohler
Recent changes RSS feed Driven by DokuWiki