DOC PREVIEW
UE CS 470 - CS 470 ­ Operating Systems Shell Project

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS 470 - Operating SystemsSpring 2012 - Shell Project40 pointsOut: January 13, 2012Due: January 25, 2012 (Wednesday)The purpose of this project is provide experience with process manipulation and signal handlers in Unix.Problem Statement1This project consists of completing a program to serve as a shell interface. That is, the program accepts user commands and then executes each command in a separate process. Unless otherwise specified, the parent process waits for the child to exit before continuing as shown in Figure 3.11 in the textbook. As is typical, the shell also will allow the child process to run concurrently by specifying the ampersand (&) at the end of the command. And finally, the shell will support a history mechanism that allows users to repeat commands previously entered.Project DetailsThis project is organized into two parts: 1. Create a child process that executes the given command that the parent may or may not wait for using the fork(), exec(), and wait()/waitpid() system calls (described in Section 3.3 of the textbook)2. Implement a history mechanism using a signal handler (notes at the end of this assignment and covered in lecture on 1/13/2012)Base shell code and the signal handler demonstration code from lecture is written in C and is available in the directory /home/hwang/cs470/project1. However, this project may be written in any language as long as it supports process creation and signals, and runs on csserver.Simple ShellThe program in shell.c provides the basic operations of a command line shell. The program consists of two functions: main() and setup(). The setup function reads in the user's next command (up to 80 characters), and then parses it into separate tokens that are used to fill the argument vector for the command to be executed. Note that the setup function creates the args array by manipulating inputBuffer. It replaces all whitespace and any & in inputBuffer by the null terminator. The elements of args are pointers to the first letter of each word in inputBuffer. If an & is encountered, the background parameter is set to inform the main program. The program is terminated when the user enters Ctrl-d which causes the setup function to invoke exit().The main function presents the user prompt and then invokes the setup function, which waits for the user to enter a command. When the setup function returns, the args array is suitable for passing on to 1 This project is based on the UNIX Shell and History Feature project published in previous editions of the course textbook: Sibershatz, Galvin, and Gagne, Operating Systems Concepts, 7e, John Wiley & Sons, Inc., 2005.01/12/2012 Page 1 of 4 D. Hwangthe execvp() system call. For example, if the user enters "ls -l" at the prompt, args[0] is the C-style string "ls" and args[1] is the C-style string "-l".Creating a Child ProcessThe first part of the project is to modify the main function so that upon the return of the setup function, a child process is forked and executes the command specified by the user using the execvp() system call, which has the following interface: execvp(char *command, char *params[]);where command is the command to be performed and params stores the command line. Thus for this project, the call should be execvp(args[0], args). The background variable determines whether the parent process is to wait for the child to exit or not.Creating a History MechanismThe second part of the project is to add a history mechanism that allows the user to access up to the 10 most recently entered commands. The user will be able to list these commands, with the least recent command listed first and the most recent command listed last, by pressing Ctrl-\ (control-backslash), which generates the SIGQUIT signal. As noted below, if the list is displayed from within the handler, the write system call must be used, since printf is not signal safe.Also note that after a signal handler is called, control goes back to the location of the interruption. For this project, this likely will happen someplace in the middle of the read system call, which causes the system call to fail and return a negative value. The shell program should ignore such attempts to read, and loop back to reissue the prompt and the read call in this case so that a user can ask for the history as many times as they wish.From the history list, the user can run any of the previous 10 commands by entering "!x" where 'x' is the first character of that command. If more than one command starts with 'x', the most recent one is executed. Also, the user should be able to run the most recent command again by entering "!!". Any command executed from the history list should be echoed on the screen and placed in the history list as the next command. Note that this is the actual command executed (e.g. "ls -l", not "!l" or "!!". Here is a short example:$ ./shellCOMMAND-> ps<ps output>COMMAND-> ls -l<ls -l output>COMMAND-> pwd<pwd output>COMMAND-> !!<pwd output>COMMAND-> !l<ls -l output>COMMAND->^\ps01/12/2012 Page 2 of 4 D. Hwangls -lpwdpwdls -lCOMMAND->^D$It may be assumed that history commands will be well-formed consisting of '!' followed immediately by a character followed by a newline. I.e., you may ignore any extra characters that appear after the second character in commands starting with '!'. If the user attempts to use the history mechanism incorrectly (i.e., there is no command starting with 'x'), an error message should be displayed and the command not entered into the history list, and of course, execvp should not be called. Note this is only for history usage errors and will not prevent erroneous commands that appear to be valid from being added to the history list and attempted to be executed; handling this is beyond the scope of this project.Assignment(20 points) Implementation of the shell program described above. This project is to be done individually. While there are no explicit design guidelines for this course, programs should exhibit a modular or object-oriented design. Projects exhibiting particularly poor design will not earn full credit. This project may be written in any language as long as the language supports process creation and signals, and runs on csserver. Please note that the instructor will only be able to provide assistance for projects written in C/C++/Java. Provide a makefile that will make your project if it needs to be compiled.(10 points) Provide a high-level discussion of the


View Full Document

UE CS 470 - CS 470 ­ Operating Systems Shell Project

Download CS 470 ­ Operating Systems Shell Project
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view CS 470 ­ Operating Systems Shell Project and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view CS 470 ­ Operating Systems Shell Project 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?