讲解Command Shell、辅导via Github留学生、讲解CS/python, C/C++编程设计

Assignment 3

Writing a Basic Command Shell

Author: Brian Crites

This project must be done in a group of two

Coding Requirements

The Test Command

For this assignment, you will add the test command to your rshell, as well as its symbolic

equivalent [ ]. The square brackets [ ] are actually set up as the test command in bash, you can

read about it here and try it out on your own. This command returns 0 (TRUE) if the test

succeeds and 1 (FALSE) if the test fails. This command is very useful for writing conditions that

can be combined with && and || to write more complex bash command structures.

IMPORTANT: You cannot use execvp to run the test command as you did in assignment 2. You

must write the functionality yourself.

Your subset of the test command is only responsible for a subset of file testing and should allow

the user to run the command using the keyword test

$ test -e test/file/path

Additionally, your rshell should allow the user to use the symbolic version of the command

$ [ -e test/file/path ]

You command should also allow the user to run tests using the following flags

-e checks if the file/directory exists

-f checks if the file/directory exists and is a regular file

-d checks if the file/directory exists and is a directory

If a user does not specify a flag, then the -e functionality will be used by default.

You will also add an extra feature that the test command currently does not have. Your test

command will print out to the terminal if it evaluated to True or False

If the command test -e /test/file/path evaluates to True, then print display the

following

(True)

And likewise, if the above command evaluates to False, then print False in the same manner

(False)

Additionally, your test command should work with the connectors && and || that you have written

previously in assignment 2, as well as all other functionality from assignment 2.

$ test -e test/file/path && echo “path exists”

- or -

$ [ -e test/file/path ] && echo “path exists”

This will check if path exists at /test/file/path, and if path does exist will print “path exists”.

When your input requires you to have multiple outputs, simply print the (True) or (False) labels

as they are evaluated, so the above command (assuming the path exists) would print

(True)

path exists

Your test function should be designed to work with both full directory paths and relative directory

paths. In order to create this command, you will need to use the stat() command, which you can

read about here. You will need to use the stat() function along with the S_ISDIR and S_ISREG

macros in order to implement all the flags required for this program.

The Precedence Operators

Additionally, you will implement parentheses ( ) as precedence operators in your rshell. The

parentheses ( ) operators are used to change the precedence of the returns of commands,

connectors, and chains of connectors. For example

$ echo A && echo B || echo C && echo D

Would print the following

A

B

D

However, we can add parentheses to change the precedence of the connectors

$ (echo A && echo B) || (echo C && echo D)

which would print

A

B

This is because the parentheses change the precedence, so that when (echo A && echo B)

returns true (since it executes correctly) to the || operator then it will not run the entire group

(echo C && echo D) since the parentheses have now grouped these commands together. Note

that if for some reason echo A failed, echo B would not execute, and (echo C && echo D) would

be executed.

If you are unsure about how the parentheses will change how a set of commands runs, try out

some examples in your terminal.

IMPORTANT: While the above example only shows a single parenthesis, you must account for

multiple nested parentheses in your implementation.

IMPORTANT: If there is an uneven amount of parentheses, you should simply error gracefully.

Submission

Make sure all branches are merged into the master branch, create a tag called hw3. Make sure

the master branch is committed and pushed to your remote repository. You should also update

your the design document that you created for Assignment 1 with the additional classes that you

added to your system, as well as updating any previous classes that you modified.

NOTE: git push will not automatically push tags to your repository. Use git push origin hw3 to

update your repository to include the hw3 tag. Additional information about git tags can be found

here.

IMPORTANT: You should verify these commands work for your repository by cloning a fresh

copy of your repository, checking out the tag, and confirming everything functions correctly. If

you forget how to use git, two students from previous cs100 courses (Rashid Goshtasbi and

Kyler Rynear) made video tutorials on the git commands needed to submit your assignments via

Github.

Do not wait to upload 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. NO

EXCEPTIONS.

Project Structure

Your project structure should follow the structure outlined in Assignment 2. You should add

additional unit tests using the Google Test framework for the additional classes, functions, and

systems that you create for this assignment as well as keeping and updating (if necessary) the

tests for the classes, functions, and systems used in the previous assignment. The additional

functionality created for this assignment should not break any of the functionality from the

previous assignment and should work seamlessly with it. You should also create bash scripts as

integration tests for your system to validate that all the components work together as expected

by the user. This type of testing is much more efficient than testing it by hand after each change.

Your code must not generate any warnings during compilation, and you must follow the CalTech

coding guidelines, as stated in the syllabus. Your final rshell and test executables must have no

memory leaks.

Collaboration Policy

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. You are allowed to freely

share ideas in this regard.

You are ENCOURAGED to look at bash's source code for inspiration.

Grading

Rubric

Points Description

5 Code comments

5 Following style guidelines

10 Updated design document

10 Sufficient test cases

35 Test operator (including integration with precedence and past requirements)

35 Precedence operators (including integration with test and past requirements)

100 Total

IMPORTANT: Your project structure is not explicitly listed in the grading schedule above,

however not following the correct structure will result in a 20 point deduction.

IMPORTANT: Projects that do not correctly compile as described previously will receive no

points