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?
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**: Since fgets() reads in at most one less than size characters from stream and stop reading after an EOF or a newline. Therefore, it's helpful since we have to read input line by line. Also, it stores a terminating null byte after the last character, which is so helpful when we do other steps to store the last command to the command list.
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?
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**: Using malloc() to dynamically allocate memory for cmd_buff to avoid some segmentation faults like memory overflow when using fgets() to read input
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?
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**: It's necessary since leading and trailing spaces may cause some potential issues because these spaces may act as a part of the command's executable name or arguments, leading to unexpected behavior.
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.
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.
- 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**: \\
Example 1: We should implement redirection that overwrites output to a file. Challenges we may have are validating existed name files and creating new file if it doesn't exist, validating the syntax. A problem may causes is multiple characters '>', or multiple spaces. We should handle this to make sure that it doesn't cause any unexpected behaviours.
Example 2: We should implement redirection that read input from a file. It's helpful in many cases. Challenges are quite the same as the first example
Example 3: We should implement redirection of stderr to a file so save the stderr messages. Except above challenges, we need to care and store the exit status.
- 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.
- 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**: The differences between its and the redirection purpose are: the pipes are used to make a more complex processing such that we can use output from stdout of a command directly to another command without having to store it. Regarding the redirection, we want to control the destination of the input/output, not necessarily use this right after.
- STDERR is often used for error messages, while STDOUT is for regular output. Why is it important to keep these separate in a shell?
- 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**: Since STDERR is often used for error messages, we usually use it to debug errors related to the operation of the code. On the other hand, STDOUT is used for regular output, which allows us to check the output of codes that run successfully (no error), to see whether there is any potential logic issues, not the code itself. Also, the exit status are usually different.
- 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?
- 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_
> **Answer**: We may merge them if the command output any to STDOUT before STDERR. It can't have any output to STDOUT after STDERR since the program stops when it has an error. To merge them, we may print both to the terminal as a regular output, then redirect them to a file if needed.
