CS31 Lab 6 Part 1: C Shell program

NOTE: each part of this lab has a separate git repo. You need to push your solution to each parts to their corresponding repos before the due date. Here is a link to the Lab 6 Part 2 assignment.

By the checkpoint, you should have completed Part1, the shell program. We encourage you to get started on Lab 6 Part 2 before the weekly lab 11 meeting next week.

Your shell should support running programs in the foreground (e.g. ls -l)

Your shell should support running programs in the background (e.g. ./sleeper &)

Your shell should support the built-in command exit to terminate.

Your shell should support the built-in command history that keeps a list of the MAXHIST most recently entered command lines entered by the user. Use a constant definition for MAXHIST, and submit your solution with it set to 10, but try your shell out with other sizes too.

Your shell should support running commands from the history using !num syntax, where num is the command ID of a command from your command history (e.g. !33 should execute the command with command ID 33 from your history list). If a matching command num is not found the current history list, then your shell should print out and error message (command not found), otherwise the command line from the matching command on the history list should be executed (again).

Use the execvp version of exec for this assignment and waitpid instead of wait. See the "Tips" section below for examples.

You need to add a signal handler for SIGCHLD signals so that you can reap exited child processes that are run in the background. You should not leave any zombie children!

Whenever your code calls a library or system call function that returns a value, you should have code that checks the return value and handles error values.` You can call exit for unrecoverable errors, but print out an error message first (printf or perror for system call error return values).

The only global variables allowed are those associated with the history list and its state. All other program variables should be declared locally and passed to functions that use them.

For full credit, your shell should use good modular design, be well-commented and free of valgrind errors. The main function should probably not be much longer than that in the starting point code. Think about breaking your program’s functionality into distinct functions.

Implement and test incrementally (and run valgrind as you go). Here is one suggestion for an order to implement:

Read the parsecmd.h file comments to see how to use the parse_cmd function. Use this function to create the argv array of strings from the command line string. This is the argv value passed to execvp.

The maximum length of a command line is defined in parsecmd.h. You can use the MAXLINE constant in your program.

Use the functions execvp(), waitpid(), and signal() for executing programs, waiting on children, and registering signal handlers. Note that the first argument to waitpid is the process id (PID) of the process you’d like to wait for, but if you pass in an argument of -1, it will wait for ANY reapable child process. This is useful inside your SIGCHLD handler, where you won’t know which child (or children) exited. You can pass it WNOHANG as the third parameter to prevent it from blocking when there are no children to reap.

You can call fflush(stdout); after any calls to printf to ensure the printf output is written immediately to the terminal. Otherwise, the C standard I/O library might buffer it for a short while.

circular queue: I suggest first implementing the Wednesday lab circular queue of ints program, and then once you get that working implement your circular array of strings in your shell program. If you get stuck on the circular queue part, start with a simpler version, where the first history list element is always in bucket 0 and the last in bucket MAXHIST-1, and then shift values over as you add a new command to the last bucket each time. Then, come back to this later and try to turn this into it a circular queue (which, for large MAXHIST values, is much more efficient than having to shift values over to maintain the queue ordering).

built-in commands: your shell should read in and parse built-in commands just like regular commands. I recommend checking for a built-in command after calling parse_cmd, which strips off any leading or trailing white space characters. Remember you can use strncmp to compare two string values. Individual char values can be directly compared using relational operators (i.e. argv[0][i] is a char value you could directly compare to a character literal like x:

if (argv[0][2] == 'x') { ...}

Remember that for any C string, a substring starting at bucket i in the string is also a C string. For example:

str = "hello";
printf("%s\n", str);      // prints the string hello
printf("%s\n", &str[1]);  // prints the string ello
printf("%s\n", &str[2]);  // prints the string llo

atoi can be used to convert a string to an int value (see last week’s lab examples).

For executing !num commands, you can use the parsecmd library to create the argv list from the command string in the history. If you have used good modular design so far, you should be able to just make calls to existing functions to execute the command.

Remember that you know how to define and use structs in C, and that you know how to use strings in C. See past weekly lab code, your lab solutions, and my C documentation.

  char str[20];
  strcpy(str, "hello");
  if(str[2] == 'x') {
    printf("x in 2\n");
  }
  if(strcmp(str, "yo ho ho") == 0) {
    printf("str seems like a pirate\n");
  }

cleaning up zombie children. Your correct shell program should reap all exited children and not leave around zombie children after it exits. However, in its development stages, you may find that it creates zombie processes that it never reaps. You should check for, and kill, all zombies after running your shell program.

  ps
  233  pts/7   00:00:01  sleeper <zombie>

  kill -9 233       # kills the process with pid 233
  pkill -9 sleeper  # kills all sleeper processes

When in doubt about what your shell should do, try running the command in the bash shell (a standard system terminal) and see what it does. For example, here is a way to see how bash executes the history built-in command: example of history and !num in bash.

Class piazza page for questions and answers about lab assignment

CS31 github org

Git help and Git for CS31 labs

Some Useful Unix Commands

vi (and vim) quick reference

Dive into Systems, Chapter 13.4.1 Signals and writing signal handlers (SIGCHLD example)

Dive into Systems, Chapter 2.9.5 Using C libraries

Week 10 Weekly Lab Examples using a C library, signals and signal handlers, circular arrays

Dive into Systems, Chapter 2 on C programming

Dive into Systems, Chapter 3 on gdb

GDB guide

Week 5 with gdb and valgrind examples

compiling and running C programs on our system

C code style guide

make and makefiles