jeffchouass
2002-01-23, 07:45 PM
誰能用C++寫這程式? Please e-mail me ! thanks!
Exercise Goal You will learn how to write a UNIX shell program to support background
processes, I/O redirection, and pipe commands. This will give you the opportunity to learn how
child processes are created to perform large grained work, and how the parent processes can
follow-up on the work performed by a child process. To accomplish this exercise, you need to be
familiar with the following concepts: process, fork system call family, exec system call family,
the pipe system call, and the standard file descriptors.
Assignment: Write a Unix shell program that acts as a command-interpreter interface
between the LINUX operating system and the user. The shell will use a number of system calls.
Some commands will be built into the shell itself, which means that those built-in commands only
change internal status of the shell program.
In this assignment you SHOULD NOT use the corresponding system commands to implement
the built-in commands. Commands that are built into the shell are:
cd - Change current working directory. The new directory would be given by an optional
command-line argument. When no argument is given, it should change to the user's home
directory.
pwd - Return the current working directory name.
setpath - Set the environment variable MYPATH. The new path will be given by an optional
command-line argument. When no argument is given, MYPATH is set to an empty string. It then
shows the current MYPATH. In this lab, MYPATH will be a string of directories separated by ':'
such as "/bin:/usr/bin". Initially MYPATH is set to an empty string.
addpath - Add the given directory at the end of the environment variable MYPATH. It
accepts one required command-line argument. If the given argument is a directory, add it to
MYPATH; otherwise, report an error and do not add it to MYPATH. In either case, your shell
then shows the current MYPATH.
history - "history" command to keep the previous 10 commands(Try man -s 1 history). The
functionality should follow the UNIX history command. When the history command is typed
from inside your command interpreter, the last 10 commands, along with their argument lists, and
command numbers should be displayed. The oldest command should always have command
number 1. Note that you should not fork a process to implement this.
!<integer>, - In UNIX you can execute a command by typing !<integer>, where <integer>
refers to a command number in the history. Add this capability to your shell.
exit - quit from the program.
Any additional input is assumed to be an executable program with the following format:
command argument_1 argument_2 ....
A command may not require any arguments. Here an empty line is also a legal input and your
shell should be simply ready to accept another command. If the input command contains a slash
character, the corresponding file will be used directly. Otherwise, your shell program will first try
to find the program by searching through the directories specified in MYPATH first. Then your
shell will attempt to run the program (using fork and execve system calls to create a child
process). For external commands, your shell program should allow the following features.
1. Both foreground and background executions are allowed. '&' at the end of a command is
used to indicate background execution (in other words, the parent will not wait for the
child process to finish). Commands without '&' are assumed to run in foreground mode.
2. Your shell program should allow I/O redirection. '<' is used to redirect the standard input
from a file and '>' is used to redirect the standard output to a file.
3. Your shell program should allow a pipe between two commands indicated by '|', .i.e, the
output from the first program is used as the input to the second program.
4. Your shell should allow a user to run two commands separated by ";" sequentially in one
command line. For example, if a user types in "ls ; pwd", your program should first
execute "ls" and then "pwd".
For the basic requirement, no more than one special control character ('&', '<', '>', '|', ';') is allowed
in any command and these special control characters only apply to external commands. You can
also assume that there will be at least one white space before and after each special control
character unless it is the very last one in the command line.
Additionally, your shell should be able to handle CTRL-C in the following way. If a program is
running in the foreground mode, your shell should ignore signal CTRL-C. However when no
program is running in the foreground mode, your shell should abort the user's current input and
start to accept a new command.
Your shell should use the same syntax as csh, a popular UNIX shell, which means that your shell
should behave similarly to csh given the samilar command. As in UNIX shells, these commands
are case-sensitive. For example, your shell program shall NOT accept "CD" as a built-in
command. You should compare the behavior of your program with the csh program for similar
commands and when you have questions about the behavior of your shell.
Hints:
1.When reading man pages, pay attention to the "SEE ALSO" section.
2.When processing the PATH environment variable, the strtok() library function may be of
use. See string(3C) for details.
3.In order to see if a named file is in a specific directory, the opendir(3C) and readdir(3C)
library functions may be of use.
Extra Credit:
Please state clearly in your README if you have implemented one or both of the following
options for extra credit.
Multiple Special Control Characters(10 points) - Your shell program should handle all
legal combinations of special control characters ('&', '<', '>', '|', ';') in one command line. As one
example, your program should allow:
"ls | cat > tmp.out", or
"ls -l > tmp.out ; cat < tmp.out > tmp.out2 ", or
"ls | cat | wc"
Command Hashing (15 points) - Your shell will create a hash table for all the executable
programs in the directories specified in MYPATH. When an external command that does not
contain a slash is given, instead of searching through the directories, your shell should find the
location directly from the hash table. The hash table needs to be updated when addpath or setpath
is used. For this option, you need to implement the following internal command.
hash - Show the hash location. It accepts one optional argument. If there is no commandline
argument, it displays the entire hash table. Otherwise, it shows the hash location of the given
command.
Deliverables
1. A design description written in English and submitted electronically with your turnin. The
description should explain the design of your shell.
This is in addition to any explanatory comments in the code. Comments are NOT a
design description. The goal here is to discuss the high-level architecture of your shell.
You may use psuedo-code or explanatory paragraphs. Start at the high level and break it
down until it is clear. System calls are important and should have a place in your
description. You need not explain the system calls but rather how your shell uses them.
Your submission should be a pdf file called design.pdf. Use ps2pdf on hill to convert a
ps file to a pdf file.
2. The code for the shell. The code must be written in a readable style and be clearly
documented with meaningful comments. The code should be written in C++.
A README file is required that provides addit ional information the grader should be
aware of.
3. A Makefile is required to compile the shell. Shells that are submitted without a Makefile are
considered programs that do not compile. Programs that do not compile on hill, no
matter how much code was written, will not receive credit. Programs that work at home
should not be expected to compile on hill without some debugging.
4. A test plan. I.e., make up a set of test cases that you will execute to test the shell. Use the
script(1) command to execute your testcases and turn in both your test cases and script
output (the typescript) file. Use script like this:
% script
do test case 1
do test case 2
etc.
% Cntrl-D (eof) --> all test input/output goes to file called
'typescript'.
Additional Information:
The Nutt lab text provides background and a strategy for implementing the shell. The section
begins on page 67 in the kernel projects book.
The following system calls/functions are helpful to review before beginning the assignment:.
fork wait
execve dup
getenv pipe
setenv close
getcwd open
chdir man page for hash command
贊助商連結
Exercise Goal You will learn how to write a UNIX shell program to support background
processes, I/O redirection, and pipe commands. This will give you the opportunity to learn how
child processes are created to perform large grained work, and how the parent processes can
follow-up on the work performed by a child process. To accomplish this exercise, you need to be
familiar with the following concepts: process, fork system call family, exec system call family,
the pipe system call, and the standard file descriptors.
Assignment: Write a Unix shell program that acts as a command-interpreter interface
between the LINUX operating system and the user. The shell will use a number of system calls.
Some commands will be built into the shell itself, which means that those built-in commands only
change internal status of the shell program.
In this assignment you SHOULD NOT use the corresponding system commands to implement
the built-in commands. Commands that are built into the shell are:
cd - Change current working directory. The new directory would be given by an optional
command-line argument. When no argument is given, it should change to the user's home
directory.
pwd - Return the current working directory name.
setpath - Set the environment variable MYPATH. The new path will be given by an optional
command-line argument. When no argument is given, MYPATH is set to an empty string. It then
shows the current MYPATH. In this lab, MYPATH will be a string of directories separated by ':'
such as "/bin:/usr/bin". Initially MYPATH is set to an empty string.
addpath - Add the given directory at the end of the environment variable MYPATH. It
accepts one required command-line argument. If the given argument is a directory, add it to
MYPATH; otherwise, report an error and do not add it to MYPATH. In either case, your shell
then shows the current MYPATH.
history - "history" command to keep the previous 10 commands(Try man -s 1 history). The
functionality should follow the UNIX history command. When the history command is typed
from inside your command interpreter, the last 10 commands, along with their argument lists, and
command numbers should be displayed. The oldest command should always have command
number 1. Note that you should not fork a process to implement this.
!<integer>, - In UNIX you can execute a command by typing !<integer>, where <integer>
refers to a command number in the history. Add this capability to your shell.
exit - quit from the program.
Any additional input is assumed to be an executable program with the following format:
command argument_1 argument_2 ....
A command may not require any arguments. Here an empty line is also a legal input and your
shell should be simply ready to accept another command. If the input command contains a slash
character, the corresponding file will be used directly. Otherwise, your shell program will first try
to find the program by searching through the directories specified in MYPATH first. Then your
shell will attempt to run the program (using fork and execve system calls to create a child
process). For external commands, your shell program should allow the following features.
1. Both foreground and background executions are allowed. '&' at the end of a command is
used to indicate background execution (in other words, the parent will not wait for the
child process to finish). Commands without '&' are assumed to run in foreground mode.
2. Your shell program should allow I/O redirection. '<' is used to redirect the standard input
from a file and '>' is used to redirect the standard output to a file.
3. Your shell program should allow a pipe between two commands indicated by '|', .i.e, the
output from the first program is used as the input to the second program.
4. Your shell should allow a user to run two commands separated by ";" sequentially in one
command line. For example, if a user types in "ls ; pwd", your program should first
execute "ls" and then "pwd".
For the basic requirement, no more than one special control character ('&', '<', '>', '|', ';') is allowed
in any command and these special control characters only apply to external commands. You can
also assume that there will be at least one white space before and after each special control
character unless it is the very last one in the command line.
Additionally, your shell should be able to handle CTRL-C in the following way. If a program is
running in the foreground mode, your shell should ignore signal CTRL-C. However when no
program is running in the foreground mode, your shell should abort the user's current input and
start to accept a new command.
Your shell should use the same syntax as csh, a popular UNIX shell, which means that your shell
should behave similarly to csh given the samilar command. As in UNIX shells, these commands
are case-sensitive. For example, your shell program shall NOT accept "CD" as a built-in
command. You should compare the behavior of your program with the csh program for similar
commands and when you have questions about the behavior of your shell.
Hints:
1.When reading man pages, pay attention to the "SEE ALSO" section.
2.When processing the PATH environment variable, the strtok() library function may be of
use. See string(3C) for details.
3.In order to see if a named file is in a specific directory, the opendir(3C) and readdir(3C)
library functions may be of use.
Extra Credit:
Please state clearly in your README if you have implemented one or both of the following
options for extra credit.
Multiple Special Control Characters(10 points) - Your shell program should handle all
legal combinations of special control characters ('&', '<', '>', '|', ';') in one command line. As one
example, your program should allow:
"ls | cat > tmp.out", or
"ls -l > tmp.out ; cat < tmp.out > tmp.out2 ", or
"ls | cat | wc"
Command Hashing (15 points) - Your shell will create a hash table for all the executable
programs in the directories specified in MYPATH. When an external command that does not
contain a slash is given, instead of searching through the directories, your shell should find the
location directly from the hash table. The hash table needs to be updated when addpath or setpath
is used. For this option, you need to implement the following internal command.
hash - Show the hash location. It accepts one optional argument. If there is no commandline
argument, it displays the entire hash table. Otherwise, it shows the hash location of the given
command.
Deliverables
1. A design description written in English and submitted electronically with your turnin. The
description should explain the design of your shell.
This is in addition to any explanatory comments in the code. Comments are NOT a
design description. The goal here is to discuss the high-level architecture of your shell.
You may use psuedo-code or explanatory paragraphs. Start at the high level and break it
down until it is clear. System calls are important and should have a place in your
description. You need not explain the system calls but rather how your shell uses them.
Your submission should be a pdf file called design.pdf. Use ps2pdf on hill to convert a
ps file to a pdf file.
2. The code for the shell. The code must be written in a readable style and be clearly
documented with meaningful comments. The code should be written in C++.
A README file is required that provides addit ional information the grader should be
aware of.
3. A Makefile is required to compile the shell. Shells that are submitted without a Makefile are
considered programs that do not compile. Programs that do not compile on hill, no
matter how much code was written, will not receive credit. Programs that work at home
should not be expected to compile on hill without some debugging.
4. A test plan. I.e., make up a set of test cases that you will execute to test the shell. Use the
script(1) command to execute your testcases and turn in both your test cases and script
output (the typescript) file. Use script like this:
% script
do test case 1
do test case 2
etc.
% Cntrl-D (eof) --> all test input/output goes to file called
'typescript'.
Additional Information:
The Nutt lab text provides background and a strategy for implementing the shell. The section
begins on page 67 in the kernel projects book.
The following system calls/functions are helpful to review before beginning the assignment:.
fork wait
execve dup
getenv pipe
setenv close
getcwd open
chdir man page for hash command
贊助商連結