From 068fbe02531e38d7572336e1b6c8f876da16a3e6 Mon Sep 17 00:00:00 2001 From: Ansh <anshbhajjan@gmail.com> Date: Sat, 15 Mar 2025 13:57:55 -0400 Subject: [PATCH] Assignment 3 questions done --- assignments/assignment-3/questions.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/assignments/assignment-3/questions.md b/assignments/assignment-3/questions.md index 1a7511a..bc0bd5d 100644 --- a/assignments/assignment-3/questions.md +++ b/assignments/assignment-3/questions.md @@ -15,16 +15,16 @@ - 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**: _One example is output redirection with echo "Hello, world!" > output.txt . This will open a file called output.txt (or make it if it doesn't exit) and write Hello, world! to the file. Once you finish that command, you can do "cat output.txt" and it will have Hello, world! in it. Another example is input redirection with something like function < input.txt . This will use the contents of whatever is in input.txt as the inputs for the function. A final example that we can implement is appending output redirection with echo "New line" >> output.txt . This will open the file output.txt and instead of completely overwriting the file (if you called echo "Hello, world!" > output.txt then echo "New line" > output.txt, if you cat it, it will only say New line), it will just add it onto the next line in output.txt . If you used the earlier output redirection example, echo "Hello, world!" > output.txt and used the appending output redirection example, echo "New line" >> output.txt, and then do "cat output.txt", you would then read Hello, world! New line (this will be on a different line but I'm not sure how to format that here)._ - 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**: _Redirection is used to literally redirect the input or output of a command TO OR FROM A FILE. Piping will let you pass the output of one command to ANOTHER COMMAND. For example, function > output.txt will write the output of the function to output.txt, but function | function2 will use the output of function as the input for function2._ - 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**: _I think the main reason you would want to keep it seperate in a shell is just for clarity sake. WHen you're coding, you would want to keep STDOUT for any regular output that works, and STDERR specifically for error messages, so when you are testing your code, if you have your error messages as STDOUTs, how are you going to distinguish that easily vs seeing a couple STDOUTS and one big STDERR._ - 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**: _Our custom shell should use exit status codes that tell us whether a command failed or succeeded properly. If a command returns a status of 0, it means that it works, but if it returns anything not 0, then it fails, and whatever we set our values to should tell us what exactly failed. I think we should merge them so then we can see what exactly is happening. If we take the redirection examples, lets say we had function < input.txt, and it returns some stuff to STDOUT, but we also had a STDERR saying "file not found" or something like that. If we only had STDOUT, we would see where the code stops, but not the exact problem. If we only had STDERR, we would see file not found, but not what the code is doing. If we combined both, then we can see exactly what our code is doing and where/what is making it crash and giving us an error. To do this, you would need to use 2>&1, for example, function > output.txt 2>&1 will output the result of the function and any errors that it may be giving us._ -- GitLab