diff --git a/Assignment-03/dsh_cli.c b/Assignment-03/dsh_cli.c
index 29e1395043134c5d26a859a2a9f939cd41c72375..6d69e2f66c7f8588efd602a7fc0da792f3a98e8b 100644
--- a/Assignment-03/dsh_cli.c
+++ b/Assignment-03/dsh_cli.c
@@ -71,9 +71,9 @@ int main() {
}//Trimming line
if (*trimmed_cmd == '\0') {
- printf(CMD_WARN_NO_CMD);
- continue;
- }
+ printf(CMD_WARN_NO_CMD);
+ continue;
+ }
// Check for empty input
@@ -95,14 +95,14 @@ int main() {
printf(CMD_OK_HEADER, clist.num);
for (int i = 0; i < clist.num; i++) {
- if (clist.commands[i].args) {
- printf("<%d> %s [%s]\n", i + 1, clist.commands[i].exe, clist.commands[i].args);
- } else {
- printf("<%d> %s\n", i + 1, clist.commands[i].exe);
- }
- }
+ if (clist.commands[i].args) {
+ printf("<%d> %s [%s]\n", i + 1, clist.commands[i].exe, clist.commands[i].args);
+ } else {
+ printf("<%d> %s\n", i + 1, clist.commands[i].exe);
+ }
+ }
- break;
+ break;
case ERR_TOO_MANY_COMMANDS:
printf(CMD_ERR_PIPE_LIMIT, CMD_MAX);
diff --git a/Assignment-03/questions.md b/Assignment-03/questions.md
index d1c7801727bd1471627b798f0ee880abdf45aec4..266dc6980de99b9018ae7155e03faa3b3cf363e1 100644
--- a/Assignment-03/questions.md
+++ b/Assignment-03/questions.md
@@ -1,30 +1,32 @@
1. In this assignment I suggested you use `fgets()` to get user input in the main while loop. Why is `fgets()` a good choice for this application?
- > **Answer**: _start here_
+ > **Answer**: fgets is really fast, and it also reads tbe input stream safetly, and can handle inputs better.
2. You needed to use `malloc()` to allocte memory for `cmd_buff` in `dsh_cli.c`. Can you explain why you needed to do that, instead of allocating a fixed-size array?
- > **Answer**: _start here_
+ > **Answer**: The buffers fixed buffers are worse, because they can be wasteful, or even too small. So it can't handle a varied input pull as well as a dynamically allocated array.
3. In `dshlib.c`, the function `build_cmd_list(`)` must trim leading and trailing spaces from each command before storing it. Why is this necessary? If we didn't trim spaces, what kind of issues might arise when executing commands in our shell?
- > **Answer**: _start here_
+ > **Answer**: Reading strings could get messed up, because the space counts as a line so it could waste the char limits, and also make print statements hard to weird, and comparisons really hard.
4. For this question you need to do some research on STDIN, STDOUT, and STDERR in Linux. We've learned this week that shells are "robust brokers of input and output". Google _"linux shell stdin stdout stderr explained"_ to get started.
- One topic you should have found information on is "redirection". Please provide at least 3 redirection examples that we should implement in our custom shell, and explain what challenges we might have implementing them.
- > **Answer**: _start here_
+ > **Answer**: > overwrite redirection You would need to open a file and then put it into the command so there could be challenges.
+ >> Append. Adding new data to a old file seems challenging.
+ >& making sure the input is merged correctly would be hard
- You should have also learned about "pipes". Redirection and piping both involve controlling input and output in the shell, but they serve different purposes. Explain the key differences between redirection and piping.
- > **Answer**: _start here_
+ > **Answer**: Piping puts one output into another, and redirection changes where the input goes.
- STDERR is often used for error messages, while STDOUT is for regular output. Why is it important to keep these separate in a shell?
- > **Answer**: _start here_
+ > **Answer**: seperating them, makes the errors stand out and makes it more readable.
- How should our custom shell handle errors from commands that fail? Consider cases where a command outputs both STDOUT and STDERR. Should we provide a way to merge them, and if so, how?
- > **Answer**: _start here_
\ No newline at end of file
+ > **Answer**: Our command should display messages that are clear and helpful, and to merge it would be >& i think.
\ No newline at end of file