diff --git a/bats/shellp2-questions.txt b/bats/shellp2-questions.txt
new file mode 100644
index 0000000000000000000000000000000000000000..00d2e83f72e0e0af9a05f19ff14c2416ce979048
--- /dev/null
+++ b/bats/shellp2-questions.txt
@@ -0,0 +1,76 @@
+1. Can you think of why we use `fork/execvp` instead of just calling `execvp` directly? What value do you think the `fork` provides?
+
+    > **Answer**:  Because execvp substitutes a new program for the existing process image, we utilize fork/execvp. 
+    The shell would be replaced and we would be unable to process user instructions if we ran execvp straight in our shell. 
+    While the parent process (our shell) stays open to take input, the fork generates a new process that can execute the external command on its own.
+    Because of this isolation, the shell can continue to operate even in the event that the external command fails or ends.
+
+2. What happens if the fork() system call fails? How does your implementation handle this scenario?
+
+    > **Answer**:  Fork() returns -1 if it fails, indicating that no child process is formed. We verify the fork's 
+    return value in our implementation. To keep the shell from crashing when a negative result is returned, we use perror() 
+    to emit the relevant error message before continuing (or maybe ending the loop). This guarantees that the shell gracefully
+    manages system problems or resource constraints.
+
+3. How does execvp() find the command to execute? What system environment variable plays a role in this process?
+
+    > **Answer**:  In order to find the command, execvp() looks through every directory specified in the PATH environment variable.
+    In each of these folders, it searches for an executable file with the name supplied as the command. 
+    execvp() runs the command if it is located in one of the PATH directories; if not, it returns an error.
+
+4. What is the purpose of calling wait() in the parent process after forking? What would happen if we didn’t call it?
+
+    > **Answer**:  The parent process suspends execution until the child process ends when it calls wait() (or waitpid()).
+    In addition to preventing the generation of zombie processes—which happen when a child has completed execution but its 
+    exit status is not collected—this enables the shell to get the child's exit status. Without using wait(), the parent process
+    could keep running without thoroughly cleaning up the child, which might eventually cause resource leaks and process table depletion.
+
+5. In the referenced demo code we used WEXITSTATUS(). What information does this provide, and why is it important?
+
+    > **Answer**: The exit code is extracted by WEXITSTATUS() from the status value that wait() or waitpid() returns.
+     This exit code shows whether the child process experienced a problem (nonzero exit code) or finished successfully (often an exit value of 0).
+    It's crucial because it gives the shell (or script) a means of figuring out if the command that was performed was successful and, 
+    if not, of taking appropriate action or reporting problems. 
+
+6. Describe how your implementation of build_cmd_buff() handles quoted arguments. Why is this necessary?
+
+    > **Answer**:  When a token starts with a double quotation in build_cmd_buff(), the function handles all characters up to the following
+    double quote as a single parameter, even if they contain spaces. This keeps the quoted string's literal content intact. 
+    Because users frequently need to give arguments that contain spaces (such file names or messages), handling quoted arguments is essential. 
+    In the absence of this, the shell would divide these parameters into several tokens, resulting in improper operation.
+
+7. What changes did you make to your parsing logic compared to the previous assignment? Were there any unexpected challenges in refactoring your old code?
+
+    > **Answer**:  The parsing mechanism was improved over the last assignment to handle quoted texts correctly, remove duplicate spaces,
+     and reduce leading and trailing spaces. This necessitated interpreting the contained content as a single token and identifying the 
+     beginning and closing quotations. Making sure that quotations matched accurately and that no extra spaces or unexpected characters were 
+     added or deleted was an unforeseen issue. The code became more complicated as a result of balancing these instances, but the command 
+     parser became more reliable and intuitive.
+
+8. For this quesiton, you need to do some research on Linux signals. You can use [this google search]
+(https://www.google.com/search?q=Linux+signals+overview+site%3Aman7.org+OR+site%3Alinux.die.net+OR+site%3Atldp.
+org&oq=Linux+signals+overview+site%3Aman7.org+OR+site%3Alinux.die.net+OR+site%3Atldp.org&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBBz
+c2MGowajeoAgCwAgA&sourceid=chrome&ie=UTF-8) to get started.
+
+- What is the purpose of signals in a Linux system, and how do they differ from other forms of interprocess communication (IPC)?
+
+    > **Answer**:  In a Linux system, signals allow the kernel or processes to alert a process to asynchronous events 
+    (such a timer ending or a user pressing Ctrl-C). Since signals are usually used for simple notifications—sending a short number 
+    (the signal number) with little data—rather than for conveying vast quantities of structured data, they vary from other types of IPC. 
+    Signals are lightweight and often used for instantaneous interruption or termination, in contrast to message queues or connections 
+    that need explicit setup and may transport large amounts of data.
+
+- Find and describe three commonly used signals (e.g., SIGKILL, SIGTERM, SIGINT). What are their typical use cases?
+
+    > **Answer**:  Signal 9 (SIGKILL): This signal ends a process with force. It is impossible to ignore, block, or catch. 
+    When a process does not react to more polite termination requests, it is usually employed as a final option.
+    Signal 15 (SIGTERM): This is a courteous request for a process to stop. It can be captured and dealt with, enabling the process 
+    to carry out cleaning tasks prior to ceasing. Without any further arguments, it is the usual signal given by commands like kill.
+    SIGINT (signal 2): The user generates this signal, often by using a terminal and hitting Ctrl-C. It allows the user to halt an 
+    operation by interrupting a process. SIGINT can be caught by programs to clean up before ending.
+
+- What happens when a process receives SIGSTOP? Can it be caught or ignored like SIGINT? Why or why not?
+
+    > **Answer**:  The operating system instantly suspends (stops) a process that gets SIGSTOP. SIGSTOP cannot be intercepted, stopped, 
+    or disregarded like SIGINT may. This is due to the fact that SIGSTOP is made to ensure that processes cannot overrule a stop request, 
+    allowing the kernel to halt a process as required. This inability to be caught is essential for debugging and system control.
\ No newline at end of file