The purpose of this lab is to learn about process operations in Unix-based OS. There are a total of three exercises in this lab. The first exercise, which is the demo exercise, requires you to try out two system calls covered in lecture 2b. The remaining two exercises will see you building a simple shell interpreter. Since exercises 2 and 3 are quite involved, we will describe them in a separate section (section 2).

1.1 Exercise 1 [Lab Demo Exercise]

In this exercise, you will use a combination of fork() and waitpid() to perform simple process creation and synchronization. The waitpid()library call is a variant in the wait() family which enables us to wait on a specific pid. Dont forget to check the manual page (man s2 waitpid). The requirement is best understood through a sample session.

The program will read in an integer N between 1 to 9 (inclusive) which indicates the number of child processes to spawn. Each of the child processes print out a Child X[PID]: Hello! message, where X is the index number and PID is the process id of the child,. The parent process will then check for the termination for each of the child and print out the corresponding message, Parent: Child X[PID] is done.. The parent process should spawn all child processes before checking on them. This check is performed in the spawning order, i.e. Child 1, 2, N.

Note that the order in which the child process print out message is not fixed, so your output may not exactly match the sample session. However, certain order must always be respected, e.g. Child X must print the Hello message before the parent can print out Child X is done message. Due to the nature of the output, there is no sample test cases provided. [Testing hint: use the sleep() command to introduce random small delays for the child processes. Pay attention to the order of messages.]

Section 2. Command Line Interpreter (Exercise 2 and 3)

As shown during the lecture, a command line interpreter (aka command prompt or shell) involves most of the major process operations. So, you are going to implement an interpreter with various features in the remaining exercises. In exercise 2, only a few simple functionalities are required. You should take the opportunity to plan and design your code since the same code can be reused in exercise 3.

Note that when you unpacked the directories for these two exercises, youll find several C files and a file named makefile in each exercise directories in additional to the usual skeleton files ex2.c and ex3.c. These extra C files are tiny programs with various runtime behavior to aid your testing later. To build these programs, simply enter make command under the directories. The make utility invokes the gcc compiler automatically to prepare the executables for you.

Summary of the extra programs:

Due to the nature of the interpreter, it is hard to test using sample input/output. So, instead of sample test cases, a sample usage session is included in the later sections of this document.

2.1 Exercise 2 (Basic Interpreter)

Let us implement a simple working interpreter with limited features in this exercise.

For (b), you need to check whether the command_path exists (i.e. valid). This can be achieved by various methods, one simple way is to make use of a library call:

stat()

Find out more about this function by man s2 stat. This library function has various usages, and some are quite involved. However, you dont need to have the full knowledge to use this call effectively. [Hint: look carefully at the return type of this function.]

Make use of the fork() and execl() combo to run valid commands. The execl() function call discussed in the lecture is sufficient for this exercise. When using execl(), you can assume that the path of the program is the same as command line argument zero (i.e. name of the program).

Just like a real shell interpreter, your program will wait until the command finishes before asking for another user request.

Suggestions on approach:

• Modularize your code! Try to find the correct code for each of the functionality independently. Test the function thoroughly then work on another part of the program. This allows your code to be reused in exercise 3.

Sample Session:

User Input is shown as bold. The prompt is YWIMC, short for Your whim is my command J, just a way to show your shell interpreter is a devoted servant. Note that additional empty lines are added in between of user inputs to improve readability.

YWIMC > /bin/ls //See note*

a.out ex2.c //output from the ls command

YWIMC > ./alarmClock //Use the provided program

Times up. 3 seconds elapsed. //after ~3 second delay

YWIMC > ./anything

./anything not found // ./anything does not exist

YWIMC > quit

Goodbye! // Interpreter exits

Note*: The ls command may be located at a different location on your system. Use whereis ls to find out the correct path for your system.

2.2 Exercise 3 (Advanced Interpreter)

This exercise extends the capabilities of the interpreter from exercise 2. Please note the enhanced or new requests below:

Notes: ^o You need to learn a few C library calls by exploring the manual pages. Most of them are variants of what we discussed in lecture.

• Instead of execl(), it is easier to make use of execv() in this case. Read up on execv() by man s2 execv.
• Remember to use the waitpid() call in exercise 1.
• You only need a simple way to keep track of the background job PIDs. (hint: a simple array will do.).

Suggestions on approach:

• This exercise is fairly involved. Again, implement the required functionalities incrementally is the best approach.
• You will need to manipulate string to some extent. Try to write a program just to test out your code first. [Warning: String manipulation is pretty frustrating in C. Dont be demoralized. J] [Hint: take a look at the sample programs]

Sample Session:

User Input is shown as bold.

Note*: The background job printing will intermix with your interpreter input / output. There is no need (and no way J) to make background job print nicely.