questions.md

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 fgets() is a good choice because it reads a full line of input, including spaces, up to a defined buffer size. Unlike scanf(), which stops reading at whitespace, fgets() allows users to input entire commands with arguments. fgets() prevents buffer overflows by limiting input to a specified size and ensures input handling remains safe. Since it stops reading at a newline (\n) or EOF, it is well-suited for a shell-like application that processes commands line by line.

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 Using malloc() allows for dynamic memory allocation, which enables our shell to handle arbitrarily long commands. If we were to use a fixed-size array, we would be limited to a predefined buffer size, potentially truncating long user input. By using malloc(), we can allocate only the necessary memory and free it when no longer needed, improving memory efficiency. Dynamically allocated memory persists beyond the function scope, ensuring that cmd_buff remains valid while processing the command.

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 Trimming spaces ensures that the command and its arguments are correctly processed. If leading spaces are not removed, the first word of the command might be misinterpreted as empty, causing execution failures. Trailing spaces can also interfere with argument parsing, leading to incorrect command execution. If spaces are not removed, duplicate or unintended entries could be stored, making it harder to correctly identify commands and their arguments.

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

    ls > output.txt
  

  Our shell must detect > and open the specified file for writing while redirecting STDOUT to that file.

    echo "Hello" >> log.txt
  

  Unlike >, this must append instead of overwriting, requiring careful handling of file modes.

    wc -l < input.txt
  

  The shell must open the file, redirect STDIN, and ensure proper cleanup after execution.

• 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

  Redirection (>, <) modifies the source or destination of input/output, typically involving files. Piping (|) connects the output of one command as the input of another. Redirection is used for file I/O, whereas pipes are for chaining command execution.

• 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

  Separating STDERR from STDOUT ensures that error messages do not interfere with regular command output. This distinction allows users to redirect and handle error messages independently. If errors were mixed with standard output, it would be difficult to parse logs, scripts, or automation tools.

• 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

  • Detecting non-zero exit statuses and providing meaningful messages.
  • Allowing users to merge STDERR and STDOUT, using:

  command 2>&1

  which redirects STDERR to STDOUT, allowing both to be captured together.

  • Providing error logging support, so failed commands can be debugged easily.