讲解Basic Command Shell、C++语言辅导、C++程序调试、辅导square brackets 辅导留学生 Statistics

Assignment 2
Writing a Basic Command Shell
This project must be done in a group of two
Coding Requirements
Develop a command shell called rshell in C++ which is capable of performing the following
steps:
1. Print a command prompt (e.g. `$`)
2. Read in a line of command(s) (and connector(s)) from standard input
3. Execute the appropriate commands using fork, execvp, and waitpid
Commands will have the following format (note that the square brackets represent optional
portions of an input):
$ executable [argumentList] [connector] [executable] ...
Where there can be any number of commands (which are composed of executables and
argument lists) separated by either ||, && or ; which are the only valid connectors. The
executable can be any executable program located at one of the PATH environment variable
locations and the [argumentList] is a list of zero or more arguments separated by spaces.
Note: The [argumentList] can also be surrounded by quotation marks which you must account
for. For instance, the command echo “hello && goodbye” would have the “hello &&
goodbye” be the [argumentList] even though without the quotes the && would separate the
goodbye into its own executable.
You will use the execvp command to run the executable from one of the PATH locations. The
connector is an optional way you can run multiple commands at once. If a command is followed
by ;, then the next command is always executed; if a command is followed by &&, then the
next command is executed only if the first one succeeds; if a command is followed by ||, then
the next command is executed only if the first one fails.
Note: you may have questions about how a specific command or set of commands should
execute. If you are unsure how a certain combination of true/false executions and connectors
will function you should test this on hammer.Note: Most bash commands are actually executables located in PATH directories such as
/bin, /usr/bin/ (e.g. ls), but some commands are built-in to bash (e.g. cd). So while the
ls command should "just work" in your shell when using execvp, the cd command won't and
isn't required to for the assignment. Only commands that can be executed through a PATH
directory need to be accounted for in this assignment.
The connectors do not impose any precedence and the command line should be execute from
left to right. For example:
$ ls -a
$ echo hello
$ mkdir test
is equivalent to:
$ ls -a; echo hello; mkdir test
Note: you can assume that there will always be a space after the semi-colon (;) connector
and before and after the and (&&) and or (||) connectors.
You are required to use the composite pattern when representing the commands and
operators in your program. There should be no limit to the number of commands that can be
chained together using the connections, and your program must be able to handle any
combination of operators. For example, you should be able to handle the command:
$ ls -a; echo hello && mkdir test || echo world; git status
When executing a line of commands, you will need to account for the following requirements:
1. Execute the commands using the syscalls fork, execvp, and waitpid. Previous cs100
students created two video tutorials a fun cartoon tutorial as well as a more serious
explanation, and should refer to the man pages for detailed instructions.
2. Every time you run a syscall, you must check for an error condition and if an error occurs
then call perror. For examples on when, how, and why to use perror, see this video
tutorial or the official man page.
3. You must have a special built-in command of exit which exits your program. This
command should also adhere to the connector rules when deciding when/if it should be
executed.
4. Anything that appears after a # character in the line should be considered a comment.
For example, in the command ls -lR /, you would execute the program /bin/ls
(performed using execvp) passing into it the parameters -lR and /. But in the commandls # -lR /, you would execute /bin/ls, but you would not pass any parameters
because they appear in the comment section. You should also note that the # may or
may not be followed by a space before the comment begins
Note: Building the parser for this program is one of the most important parts. There are many
ways accidentally introduced bugs into your program and you will be adding more parsing
features in future assignments. You can create your own parsing function from scratch or use
the strtok function from the C standard libraries or the Tokenizer class provided in the boost
library.
Important Notes for Hammer
The hammer server is provided by the CS department as a standard environment which you
can use to test your code in the same environment that it will be graded in. However, because
everyone in the class is using this server to run their assignments there are some imposed
limitations around the number of processes you can run to keep the server running well. Please
take very special note of the following advisories when using the hammer server.
● No Graphics: because hammer is a true server you will not have access to any
applications which require graphics such as web browsers or graphical editors.
● One SSH Session: because the hammer server limits the number of processes you can
run at any given time if you are connecting to hammer through multiple sessions (ssh,
putty, etc.) this will limit the number of other processes you can run. For this reason you
should only use a single connection, if you need multiple windows there are other
methods (screen, sleeping processes, etc.) to navigate the system better without
multiple connections. You should also properly close your SSH connection so that they
do not continue to live on the server side. This is typically done by executing exit on
the command line you are connected to.
● Be Careful when Forking: each time you execute a fork() function you are creating a
new process which will execute until it terminates (via exit() or some other program
termination). One very common issue is for students to create fork() program that do not
properly exit and instead build up over time until they use up all the processes you are
alloted on hammer, at which point you will not be able to ssh or perform other normal
programs (because you have no available processes).
In order to check for this issue you can use the command line command ps -uxwwf and look
for a buildup of processes (typically named after the program you are executing like rshell). You
can then destroy any accidental processes using the command kill -KILL where
you replace with the PID number that displays when you run ps -uxwwf .If your session gets really stuck, you can use killall -KILL -u to kill all the
processes you own (you must use your own username) which will disconnect you and kill all the
processes you have running. Note that by killing all the processes you have running you will
lose any changes from files you were editing on the server.
Project Structure
You must have a directory called src/ which contains all the source (.cc/.cpp) files for the
project. For header files you may either have a folder header/ which contains your header files
or you may keep them in the src/ directory. You must have a unit_tests/ directory which
should contain all the unit tests you've written using the Google Unit Test framework (the main
for the unit tests can be located either in unit_tests/ or src/). You must also have an
integration_tests/ directory which should contain all the integration tests you’ve written
using bash. We recommend using IO redirection for your bash integration tests, and automated
validation is not necessary.
Your root directory must have a CMakeLists.txt with two targets. The first target is named
rshell and should build the main executable and the second should be test which runs the
unit tests that you have created using the Google Unit Test framework.
Note: The file/directory names above are a standard convention. You must use the exact
same names in your project, including capitalization. We utilize these names when performing
steps of our automated grading process, so any deviation may result in missing points.
The google test code for your unit tests can have any name as long as the files reside in the
unit_tests/ directory and an executable is generated named test in the root directory. The
integration test shell scripts that you develop and place into the integration_tests/
directory must have the following names:
single_command_tests.sh tests primarily for command executions
multiple_commands_tests.s
h
tests primarily for command and connectors interaction
commented_command_tests.s
h
tests primarily for comments being respected
exit_command_tests.sh tests primarily for proper exit functionality
Your project should not contain any files not necessary for the project. This includes things like
CMake temporary build files used for building the project on your machine such as
CMakeCache.txt and the CMakeFiles/ directory as well as executables. We have provideda .gitignore in the template repository which will stop may of these files from showing as
untracked when you run git status, and you should extend this file with additional temporary and
machine specific files.
Submission Instructions
You will also need to add an annotated hw2 tag to the commit that you want to be graded.
Annotated tags are described in lab 2 and in the git documentation. git push will not
automatically push tags to your repository. Use git push origin hw2 to update your
repository to include the hw2 tag. If you need to update your tag, you can remove the old tag
using git push --delete origin hw2 and push an updated one to your repo.
Note: We will test your project on the hammer server, so while it is not required that you
develop on hammer you should verify that your project builds and functions properly on
hammer.cs.ucr.edu.
Your project must also contain a names.txt file in the root directory which contains the name,
SID, and email of each of the partners in your group. It should have the following format.
Brian Crites, 860XXXXXX, bcrit001@ucr.edu
Andrew Lvovsky, 860XXXXXX, alvov001@ucr.edu
Do not wait to push your assignment to Github until the project due date. You should be
committing and uploading your assignment continuously. If you wait until the last day and can't
figure out how to use git properly, then you will get a zero on the assignment or be forced to use
the course late policy. No exceptions.
For late assignment submissions, a penalty of 10% will be deducted for every day the
assignment is late up to a maximum of 3 days, with exceptions only for documented
emergencies. For clarity, this means that an assignment that is 3 days late would incur a 30%
penalty to the grade assessed. Please submit this form along with your late submission.
Otherwise, the team will receive a zero on that assignment.
In addition to the above submission requirements you must update your README.md file so that
it specifies the current structure of your program. This is especially important since your final
program will likely be much different than what you originally designed in Assignment 1.Testing Your Submission
Your assignment 2 should have approximately the following structure, see the project structure
section for more details:
example-project-directory/
├── CMakeLists.txt
├── README.md
├── googletest
├── header
├── header_file_1.h
└── header_file_2.h
├── src
├── src_file_1.cpp
└── src_file_2.cpp
└── unit_tests
├── test_file_1.cpp
└── test_file_2.cpp
└── integration_tests
├── single_command_tests.sh
├── multiple_commands_tests.sh
├── commented_command_tests.sh
└── exit_command_tests.sh
You should also have a .gitignore and a .gitmodules hidden file in your root directory. Your root
directory should contain no C++ header or source files and your googletest directory should be
added to your project as a submodule. While the googletest directory is not required to be
present in the root directory it is suggested.
When testing your project we will run (approximately) the following commands on hammer:
git clone
cd
git checkout tags/hw2
git submodule init
git submodule update
cmake3 .
makeThese commands should generate a test executable as well as an rshell executable in the
root directory. Please run these commands on hammer with a brand new clone of your GitHub
repository to ensure your shell compiles and builds properly before submission.
Collaboration Policy
● You may not copy any code found online, doing so will result in failing the course.
● You may not look at the source code of any other student.
● You may discuss with other students in general terms how to use the unix functions.
● You are encouraged to talk with other students about test cases and are allowed to
freely share ideas in this regard.
Grading
10 Sufficient Unit Test Cases
10 Sufficient Integration Test Cases
10 Updated README.md
20 Single Command Execution
20 Command and Connectors Execution
20 Command with Comments Execution
10 Commands with Exit Execution
100 Total
Note: Your project structure is not explicitly listed in the grading schedule above but not
following the specified file names and location may result in losing points because the
automated grading system is unable to process your repository. Loss of points due to an
issue specified above are final and failure to build and compile will result in a zero for the
assignment.