Add "test" Command

[nestrada2]

test

The "test" command evaluates a conditional expression. It is an if statement that will return zero (true), 1 (false), or greater than 1 (error). The "test" command will check if any flags were inputted and, based on the expression, will return a truthy or falsy value.

Files Added

user:

• test.c (new: call sys_open, pass a path to that and that will give us a file descriptor. With the file descriptor we call sys_fstat, and pass in the file descriptor, and a pointer to an empty stat struct which will be populated with the file's metadata)

Expressions Implemented in Test

Command	Description
-d file	True if file exists and is a directory.
-e file	True if file exists (regardless of type).
-f file	True if file exists and is a regular file.
file1 -ef file2	True if file1 and file2 exist and refer to the same file.
s1 = s2	True if the strings s1 and s2 are identical.
s1 != s2	True if the strings s1 and s2 are not identical.
n1 -gt n2	True if the integer n1 is algebraically greater than the integer n2.
n1 -lt n2	True if the integer n1 is algebraically less than the integer n2.

Examples

Example 1: File Analysis

• test -f cat
• Expected Output: 0

Example 2: String Operators

• test "hello" = "hell"
• Expected Output: 1

Example 3: Number Operators

• test 23 -gt 32
• Expected Output: 1

Tests

Command	Description
sh test.sh	Runs a series of automated tests to validate the behavior of the program.

Note: The test script only runs if you add shell scripting support.

[andywu42]

I can code review this

[ajsdkty3]

I can code review this.

[ajsdkty3]

I really like your project! The logic for handling various file flags, string comparisons, and number comparisons works as expected. The overall structure is clean and easy to follow. Also, I really like the test script (test.sh), which covers a wide range of inputs. And I also like how when I input something wrong, it shows me what valid inputs are available.

Suggestions for Improvement:
1.The openFile function does not close the file descriptor after opening the file, which can be fixed by closing the file descriptor right after the fstat call.

2.The test.sh script is well-constructed. However, more edge cases could be added, such as empty or nonexistent files, handling special characters in file names.

High Level Checks:
✅ PR fully resolves the task/issue
✅ Does the PR have tests?
✅ Does the PR follow project code formatting standards?
✅ Does the OS still compile and run?
✅ Is documentation included?

Code Checks:
✅ Does the code achieve its intended purpose?
❌ Were all edge cases considered?
✅ Is the code organized and maintainable?
✅ Does the code maintain the same level of performance? (no performance regressions)

[andywu42]

Comments:
Good project, clean design and readability. Good JavaDoc comments and naming conventions.

Suggestions:
*I think intuitively 1 should be true and 0 false as a minor overall change (and errors as < 0). Not necessary though.
**I think some informative error messages can be displayed to help understand what they did wrong
Ex: test -d hi
Output:
Couldn't open file: hi
Result: 1
Suggestion: print “%s does not exist”, pathname
**In main() of your implementation, I think the parsing of arguments can use some revisions. Particularly, I think how you read strings should not be hard coded as just checking for a singular “ symbol
Ex: test hi != hello
Output:
Not a number: hi
…script…
Result: 2
Suggestion: Modify your reading for string tokens and maybe change the default case of the whole else if blocks is not always an assumed number parsing.
**The string checker is a bit funky with how it processes string tokens.
Ex: test "hello hi" != "hello hi"
Output:
Unknown string comparison: hi"
…script…
Result: 2
*To add to this, if you run a string comparison with the comparator in it it’ll still incorrectly run.
Ex: test "2 != 2" != extraARGS
Result: 0
Expected: Result 1 for false, since I would expect my "2 != 2" to be considered one token being compared to extraARGS, whereas I believe the logic behind this is “2 != 2” ignoring everything behind it and giving 0 for true, which is a bit strange

High Level Checks:

• PR fully resolves the task/issue
• Does the PR have tests?
• Does the PR follow project code formatting standards?
• Does the OS still compile and run?
• Is documentation included?

Code Checks:

• Does the code achieve its intended purpose?
• Were all edge cases considered?
• Is the code organized and maintainable?
• Does the code maintain the same level of performance? (no performance regressions)

[malensek]

Can't say I have any issues with this, especially after adding the tests and fixing even more issues that lie more on the xv6 side of things than yours, really. Just FYI for reviewers, in the shell true / false are flipped compared to what you'd expect in C, so that's why this is the way it is. If I had to nitpick, it needs to be reformatted in xv6 style and some of the indentation is misleading (at least on my editor), but that's not a major problem. Nice work!