CS31 Lab 8: Implementing a Unix Shell and C library

Your implementation of parse_cmd_dynamic should behave according to the specifications described above.

You may not change the prototype (argument types or return type) of parse_cmd_dynamic, and your solution should NOT use the strtok function from the string.h library.

You may assume that if an ampersand (&) appears in the command line, indicating that the command is to be run in the background, that it will appear at the end of the line. That means you can ignore any/all characters that appear after an & (except the '\0' character).

Your implementation should make no attempt to modify the input command line argument string. It should be treated as a constant. You ARE allowed to make a copy of the string (e.g. with strdup) and modify that however you’d like.

Your function should work for command line strings entered with any amount of whitespace between command line tokens (assuming there’s at least one whitespace character between them). For example, these inputs should yield identical argv lists returned by your function. (Recall the '&' character does not end up in your argv array.)

cat foo.txt  blah.txt
cat foo.txt  blah.txt      &
cat foo.txt  blah.txt&
             cat          foo.txt           blah.txt

You should fill in the missing TODO in tester.c such that, if we run your tester, it works correctly and there are no valgrind issues (like memory leaks, since there are no calls to free in the starter code).

For full credit, your solution should be well-commented, it should not use global variables, it should demonstrate good design, and it should be free of valgrind errors.

Test your code in small increments. It’s much easier to localize a bug when you’ve only changed a few lines.

In implementing parse_cmd_dynamic, you will likely want to make more than one pass through the characters in the input string.

When working with pointers, and in particular double pointers, it’s often very useful to draw some pictures about what’s pointing to what, noting the types of variables. Don’t shy away from using the whiteboard or scratch paper!

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 long-term zombies!

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.

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.

Remember that if you dynamically allocate space for a string (using malloc), you need to allocate a space at the end for the terminating null character (\0), and that you need to explicitly free the space when you are done using it. Since your parsing library is allocating memory for the argv list, it’s up to your shell to free that memory when it’s done with it.

There is some starter code for building a circular queue of integers in the in-lab exercises. You should attempt to implement that first. Once you get that working you can go ahead and implement your circular queue 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).

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.

You know how to define and use structs in C, and you know how to use strings in C. See past weekly lab code, your lab solutions, and the C documentation at the bottom of the lab writeup.

Remember that you can compare individual char values directly, but you need to use strcmp to compare two string values:

  char str[20];
  strcpy(str, "hello");
  if(str[2] == 'x') {
    printf("x is in position 2\n");
  }
  if(strcmp(str, "yo ho ho") == 0) {
    printf("strings are equal\n");
  }

You’ll need to clean up your zombie children. A 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.