Skip to content
Snippets Groups Projects
Commit 3468e5af authored by hk835's avatar hk835
Browse files

Add new file

parent 0fc33ba2
Branches main
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**: _`fgets() is a line-based function that stops reading after encountering a newline character or reaching the end of the file (EOF). This behavior makes it well-suited for reading one command per line. Additionally, fgets() prevents buffer overflows by respecting the buffer size provided, making it a safer alternative to older functions like gets(). It is also more convenient than lower-level functions when handling arbitrary input sizes._
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**: _Fixed-size arrays can be limiting when command sizes are unpredictable, leading to potential memory waste or buffer overflows. Using malloc() allows dynamic memory allocation, providing the flexibility to allocate exactly what’s needed and resize when necessary. This approach ensures efficient memory usage and accommodates varying command lengths._
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**: _Trimming eliminates unnecessary whitespace that could interfere with command parsing. Without it, extra spaces in inputs like " ls " may cause errors, misinterpretations, or difficulties in matching the correct executable._
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**: - **`command > file`**: Redirects STDOUT of `command` to `file`, overwriting it.
> - **`command >> file`**: Redirects STDOUT of `command` to `file`, appending rather than overwriting.
> - **`command < file`**: Takes input from `file` instead of the keyboard.
>
> Challenges include correctly manipulating file descriptors, verifying file write/read permissions, and handling any combination of input and output redirections together (e.g. `command < file1 > file2`).
- 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**: _Redirection and piping are two core features of shell environments that manage data flow between commands and files. Redirection connects a command’s input or output directly to a file or device. For example, using ls > files.txt saves the output of the ls command into a file called files.txt, overwriting any existing content. On the other hand, piping (|) links the output of one command directly to the input of another command without involving files. For instance, ls | grep ".txt" passes the output of ls to grep, which filters and displays only .txt files. The key difference is that redirection is used for command-to-file data flow, while piping creates a command-to-command connection._
- 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**: _In Unix-like systems, commands produce two types of output: STDOUT (standard output) for regular data and STDERR (standard error) for error messages. Separating these streams allows users and scripts to handle errors differently from normal output. For example, redirecting only the error messages to a log file can be done using command 2> error.log, which sends STDERR to a file while leaving STDOUT unaffected. If users want both error and normal outputs combined, they can use command > output.log 2>&1, which merges STDERR into STDOUT, saving both in the same file. This separation provides flexibility in managing outputs and simplifies error tracking in complex scripts._
- 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**: _Every command in a shell returns an exit status upon completion, where 0 typically means success, and any non-zero value indicates failure. The shell should detect these non-zero exit codes and handle them appropriately. For example, if a command fails, the shell can print a message like Command failed with exit code 1 to inform the user. Additionally, the shell should store this exit status for future reference, similar to how $? works in many shells, allowing users or scripts to check the success or failure of previous commands. Managing exit statuses effectively is crucial for building reliable and user-friendly shell environments._
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment