---

The purpose of this lab is to gain experience working with system calls and learn about process management. (details below).

---

Simple Shell in C++

The goal of this lab is to implement a simple shell in C++. This requires you to use system calls directly in your code. In class, we touched upon how a few system calls, (notably fork and exec) can be used to implement a command shell. In this exercise, you will implement tsh (trivial shell), a simple shell.

Like a real shell, tsh will take as input the name of a program as argument. The program can be the name of any executable in the current directory where your shell program resides. The shell should run the specified program with the arguments before prompting for a new user command. The command "quit" should terminate your shell.

Here is a simple example:

elnux25$ ./tsh
  tsh> add 2 3 // calls the add binary which should be present
  5
  tsh> quit
elnux25$

To get started, download the skeleton starter code from moodle. Do not change any file names or function names that are provided to you. Simply implement the real process logic.

Tips

• Useful functions and system calls include fork, exec (specifically the execvp variant, in conjunction with the cmdTokens variable), sleep, waitpid, and kill. You should use the SIGKILL signal value in kill to terminate a process.
• If you're trying to use waitpid and get a warning like "warning: implicit declaration of function 'waitpid'", you probably need to include an additional system header file. Add the line "#include <sys/wait.h>" to the top of your file alongside the other #include statements.
• Be careful when adding calls to fork -- if you write an infinite loop with a fork in it, a fork bomb will result. If in doubt, you can add a sleep(1); before each fork during debugging, which will slow the rate of process creation.
• tsh can execute a program with arguments, but cannot execute multiple programs using Bash constructs (e.g., 'sleep 3 && echo hello' to sleep for 3 seconds, then print hello). However, you can accomplish the same by making a new Bash file (e.g., the included 'sleephello' script) and calling that from within tsh (e.g., './sleephello'). If you do this, make sure the script you are trying to call is executable ('chmod +x sleephello').
• Since each OS has its own (different) system call interface, you should use linux machines for this lab since fork, exec are Unix/linux system calls. You can use your own machine to write the code, but you must ensure that it runs on the edlab (linux) machines.
• Do not use cygwin/windows for this lab (fork/exec) are not supported on windows.
• If you have difficulties with C++ syntax or errors, email or see the TA. While minimal features of C++ are required for this assignment, we don't want you to spend too much time debugging issues with C++ itself.

---

Design Document and Observations

Once you have written your version of the shell, write a design document that documents your design choices. The design doc should be written in plain text in a file called README.txt.

How to Turn in Lab 1

We will use an autogrder system to submit and grade your assignment.

1. Update: We will be using Gradescope for lab submissions this semester. You should be receiving an invitation email from Gradescope soon. Please sign up and submit your lab there once we set up the assignment.
2. There should be a starter_code_new.zip that you need to download from Moodle and copy whatever you have done so far into the 'src' folder or start working on your lab using the new tar file if you haven't started yet. We are also including a 'tests' folder in the starter code. The lab assignment does NOT require you to write test cases and there are no points allocated for writing test cases. Nevertheless, it is aways a good idea to do some testing of your code for any program that you write. There are many ways for you to test you code. One approach is to use a unit testing framework (something you will be expected to do if you get a programming job someday). Should you wish to write some simple test cases for your code, you can use a framework such as the Google Test Framework. Instructions on how to write test cases for C++ using GTest can be found here GTest.

   It is important that you keep the directory structure the same as what we have given to you in starter_code_new.zip. Make sure you see the path exactly the same as "/src/tsh.cpp" and "/src/tsh.h" etc. when submitting your code to Gradescope. You may not be able to receive a grade otherwise.

   To submit your code to gradescope, you need to create a zip file and upload it through your gradescope account. Your should zip your src and test folders directly into a zip file (do not zip the parent directory). You can use the following command: zip -r mycode.zip src test to create the zip file, or use any GUI based method or zip program to create the zip file. For example, on a Mac, select the src and test directory using the command key and then right click to select "Compress two items".

   Once you upload to gradescope, it will run some tests and let you know how many tests passed or if your code failed to complile or failed to terminate. We will not reveal what each test does, but you should know that we are testing basic features such as the ability to take input, process it, invoke fork/exec/wait in the proper way.

   You can submit as many times as you wish to gradescope until the deadline or until your code passes all tests.

3. This lab should be done individually (NOT in groups).
4. Include a README file containing an outline of what you did. It should also explain and document your design choices. Keep it short and to the point. If your implementation does not work, you should document the problems in the README, preferably with your explanation of why it does not work and how you would solve it if you had more time.
5. Note: We will strictly enforce policies on cheating. Remember that we routinely run similarity checking programs on your solutions to detect cheating. Please make sure you turn in your own work.

   You should be very careful about using code snippets you find on the Internet. In general your code should be your own. It is OK to read tutorials on the web and use these concepts in your assignment. Blind use of code from web is strictly disallowed. Feel free to check with us if you have questions on this policy. And be sure to CLEARLY document any Internet sources/ tutorials you have used to complete the assignment in your README file.

---

Lab 1 Grading Scheme

(max 100) Total Grade

• (70) autograder tests on Gradescope
• (10) design document in README.txt
• (15) use of fork/exec/wait
• (5) code comments

Late Policy: Lab 1 is due at 8 PM on Thursday, September 29. Please refer to the course syllabus for late policy on lab assignments. This late policy will be strictly enforced. Please start early so that you can submit the assignment on time.