Skip to content
Snippets Groups Projects
Commit 7699cd73 authored by Vanshika Mohan Bongade's avatar Vanshika Mohan Bongade
Browse files

Upload New File

parent 47e286b7
Branches
No related tags found
No related merge requests found
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**: Because it allows us to read a line of user input—including spaces and special characters—without risking buffer overflow, fgets() is a wise choice. It is secure since it automatically restricts the number of characters read to SH_CMD_MAX. Additionally, it handles newlines (\n) and EOF (Ctrl+D) correctly, which is crucial for a shell that analyzes user input 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**: We can dynamically allocate memory by using malloc() for cmd_buff, which avoids stack overflows when working with lengthy commands. Input length would be limited by a fixed-size array, which could result in buffer overflows if a user inputs a command that takes up more space than is allowed. Malloc() allows us to safely allocate memory and release it when it is no longer required.
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**:
Correct interpretation of orders is ensured by cutting leading and trailing spaces. If no spaces are eliminated:
Unexpected behavior could result from the shell treating blank spaces as part of a command name.
Space-only commands may be interpreted as empty commands.
Argument parsing misalignment could happen (for example, "ls -l" should be handled as "ls -l"). Trimming correctly avoids needless parsing problems and guarantees accurate command execution.
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**: ls -l > output.txt
The shell must manage file permissions, open and close the file correctly, and overwrite any existing files.
echo "New log entry" >> log.txt
To prevent the file from being corrupted by many processes, the shell must open it in append mode rather than overwriting it.
wc -l < input.txt
The file must be present, openable, and have its contents properly provided as STDIN, according to the shell.
- 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**: ls > file.txt
Rather from publishing the output on the screen, the command saves it in file.txt.
ls | grep txt
Piping (|) is used to connect the output of one command to another as input.
- 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**: Combining STDERR (error messages) with STDOUT could result in incorrect data processing, making it harder to distinguish between errors and legitimate output. By keeping them apart, users can utilize 2> for STDERR and 1> for STDOUT to independently redirect errors and standard output. Because it prevents error messages from interfering with a command's desired output, this separation is crucial for more understandable debugging.
- 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**: In order to prevent problems from interfering with normal command output, our shell should gracefully capture and handle errors by writing error messages to STDERR rather than STDOUT. When a failure happens, it should leave with non-zero error codes so that users can identify and fix faults programmatically. The shell should also include the ability to combine STDERR and STDOUT using redirection syntax such as 2>&1, allowing users to blend standard output and error messages as needed.
ls non_existing_file 2>&1
This merges error messages with output, allowing users to redirect both together.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment