Hi, can I get the answer to this question coded on C.

Thank you

Section 2. Command Line Interpreter (Exercise 2 and 3) By now you have issued a number of commands through the shell command prompt on the Compute Cluster nodes. The shell prompt is also known as command line interpreter. It is actually just another program implemented using the process-related system calls discussed in lecture. In the remaining exercises, you are going to implement an interpreter with various features. In exercise 2, only a few simple functionalities are required. You should take the opportunity to plan and design your code in a modular way, since the same code can be reused in exercise 3. Note that when you unpack the directories for these two exercises, you'll find several C files and a file named makefile in each exercise directory in addition to the usual skeleton files ex2.c and ex3.c. These extra C files are tiny programs with various runtime behavior to aid your testing later. To build these programs, simply enter make command under the directories. The make utility invokes the gcc compiler automatically to prepare the executables for you. Other than exhibiting interesting execution behavior, you can also learn a few useful tricks from these programs. Feel free to open them up and browse through the code. Summary of the extra programs: Prints out a message after Y seconds and repeat for X times. clock X and Y can be specified as command line arguments. See given code for more details. alarmclock Prints out a message after X seconds and terminates. X can be specified as command line argument. See given code for more details. infinite Goes into infinite loop, never terminates. return Return the user specified number X to the shell interpreter. showCmdArg Shows the command line arguments passed in by user. stringTokenizer Shows how to split user input into subparts (tokens). 2.1 Exercise 2 (Basic Interpreter) Let us implement a simple working interpreter with limited features in this exercise. General flow of basic interpreter 1. Prompt for user request. 2. Carry out the user request. 3. Unless user terminates the program, go to step 1. TWO possible user requests: a. Quit the interpreter. Format: quit Behavior: Print message "Goodbye!" and terminates the interpreter. b. Print the current search path: showpath . Behavior: Print the current search path (see (d) for the usage of this search path) By default, the search path is "." (i.e., the current directory). User can change it using the command setpath below. c. Change the current search path: setpath user_supplied_path Behavior: Change the current search path to user_supplied_path You can assume the search path contains less than 20 characters d. Run a command. Format: command //Read command to be executed //The command is assumed to be less than 20 characters Behavior: 1. If path/command exist, run the command in as a child process. The "path" is the current search path (e.g., can be the default "." or any path set by user via command (c) above. Wait until the child process is done 2. Else print error message "xyz not found, where xyz is the user command. 2.2 Exercise 3 (Advanced Interpreter) This exercise extends the capabilities of the interpreter from exercise 2. Please note the enhanced or new requests below: SIX possible user requests: a. [No change] Quit the interpreter. Format: quit //No change from ex2. b. [Enhanced] Run a command. Format: command (argi to arg4] I/the user can supply up to 4 command line arguments Behavior: a. If the specified command exists at path/command, run the command in a child process with the supplied command line arguments. You can assume each argument is no more than 10 characters long. Wait until the child process is done. Capture the child process' return value (see "result" command). b. Else print error message "XXXX not found, where xxxx is the user entered command. c. [New] Run a command in the background. Format: command (argi to arg4] & // Note the "&" symbol at the end of the command. The user can supply up to 4 command line arguments, same as (b). Behavior: a. If the specified command exist at path/command, run the command in a child process with the supplied command line arguments. Print "Child xxxx in background, xxxx should be the PID of the child process. Continue to accept user request. b. Else print error message "XXXX not found, where xxxx is the user entered command. d. [New] Wait for a background process. Format: wait job_pid //"wait" followed by an integer job_pid Behavior: 1. If the job_pid is a valid child pid (generated by the request in (C)) and has not been waited before: Wait on this child process until it is done, i.e., the interpreter will stop accepting request. Capture the child process' return value (see "result" command). 2. Else print error message "XXXX not a valid child pid, where Xxxx is job_pid entered by user. e. [New] Print the pids of all unwaited background child process. Format: //short for print child pc Output format: Unwaited Child Processes: // Just an output header // May be empty if there is no // unwaited child a. Behavior: PID of all "unwaited" background child processes (including terminated ones) are printed. f. [New] Print the return result (1.e. exit status of the child process just ended (foreground child) or just waited (background child). Format: result Output format: // A single integer number Behavior: a. This command is only valid after a successful (b) or (d). Assumptions: a. Non-terminating command will NOT be tested on your interpreter. b. No ctrl-z or ctrl-c will be used during testing. As we have not covered signal handling in Unix, it is hard for you to take care of these at the moment. c. Each command line argument for (b) and (c) has less than 20 characters. d. There are at most 10 background jobs in a single test session. e. You can assume all user requests are "syntactically correct". Notes: o You need to learn a few C library calls by exploring the manual pages. Most of them are variants of what we discussed in lecture. o Instead of execl(), it is easier to make use of execv() in this case. Read up on execv() by "man-s2 execv". o Remember to use the waitpid() call in exercise 1. You only need a simple way to keep track of the background job PIDs. (hint: a simple array will do....). 0 Section 2. Command Line Interpreter (Exercise 2 and 3) By now you have issued a number of commands through the shell command prompt on the Compute Cluster nodes. The shell prompt is also known as command line interpreter. It is actually just another program implemented using the process-related system calls discussed in lecture. In the remaining exercises, you are going to implement an interpreter with various features. In exercise 2, only a few simple functionalities are required. You should take the opportunity to plan and design your code in a modular way, since the same code can be reused in exercise 3. Note that when you unpack the directories for these two exercises, you'll find several C files and a file named makefile in each exercise directory in addition to the usual skeleton files ex2.c and ex3.c. These extra C files are tiny programs with various runtime behavior to aid your testing later. To build these programs, simply enter make command under the directories. The make utility invokes the gcc compiler automatically to prepare the executables for you. Other than exhibiting interesting execution behavior, you can also learn a few useful tricks from these programs. Feel free to open them up and browse through the code. Summary of the extra programs: Prints out a message after Y seconds and repeat for X times. clock X and Y can be specified as command line arguments. See given code for more details. alarmclock Prints out a message after X seconds and terminates. X can be specified as command line argument. See given code for more details. infinite Goes into infinite loop, never terminates. return Return the user specified number X to the shell interpreter. showCmdArg Shows the command line arguments passed in by user. stringTokenizer Shows how to split user input into subparts (tokens). 2.1 Exercise 2 (Basic Interpreter) Let us implement a simple working interpreter with limited features in this exercise. General flow of basic interpreter 1. Prompt for user request. 2. Carry out the user request. 3. Unless user terminates the program, go to step 1. TWO possible user requests: a. Quit the interpreter. Format: quit Behavior: Print message "Goodbye!" and terminates the interpreter. b. Print the current search path: showpath . Behavior: Print the current search path (see (d) for the usage of this search path) By default, the search path is "." (i.e., the current directory). User can change it using the command setpath below. c. Change the current search path: setpath user_supplied_path Behavior: Change the current search path to user_supplied_path You can assume the search path contains less than 20 characters d. Run a command. Format: command //Read command to be executed //The command is assumed to be less than 20 characters Behavior: 1. If path/command exist, run the command in as a child process. The "path" is the current search path (e.g., can be the default "." or any path set by user via command (c) above. Wait until the child process is done 2. Else print error message "xyz not found, where xyz is the user command. 2.2 Exercise 3 (Advanced Interpreter) This exercise extends the capabilities of the interpreter from exercise 2. Please note the enhanced or new requests below: SIX possible user requests: a. [No change] Quit the interpreter. Format: quit //No change from ex2. b. [Enhanced] Run a command. Format: command (argi to arg4] I/the user can supply up to 4 command line arguments Behavior: a. If the specified command exists at path/command, run the command in a child process with the supplied command line arguments. You can assume each argument is no more than 10 characters long. Wait until the child process is done. Capture the child process' return value (see "result" command). b. Else print error message "XXXX not found, where xxxx is the user entered command. c. [New] Run a command in the background. Format: command (argi to arg4] & // Note the "&" symbol at the end of the command. The user can supply up to 4 command line arguments, same as (b). Behavior: a. If the specified command exist at path/command, run the command in a child process with the supplied command line arguments. Print "Child xxxx in background, xxxx should be the PID of the child process. Continue to accept user request. b. Else print error message "XXXX not found, where xxxx is the user entered command. d. [New] Wait for a background process. Format: wait job_pid //"wait" followed by an integer job_pid Behavior: 1. If the job_pid is a valid child pid (generated by the request in (C)) and has not been waited before: Wait on this child process until it is done, i.e., the interpreter will stop accepting request. Capture the child process' return value (see "result" command). 2. Else print error message "XXXX not a valid child pid, where Xxxx is job_pid entered by user. e. [New] Print the pids of all unwaited background child process. Format: //short for print child pc Output format: Unwaited Child Processes: // Just an output header // May be empty if there is no // unwaited child a. Behavior: PID of all "unwaited" background child processes (including terminated ones) are printed. f. [New] Print the return result (1.e. exit status of the child process just ended (foreground child) or just waited (background child). Format: result Output format: // A single integer number Behavior: a. This command is only valid after a successful (b) or (d). Assumptions: a. Non-terminating command will NOT be tested on your interpreter. b. No ctrl-z or ctrl-c will be used during testing. As we have not covered signal handling in Unix, it is hard for you to take care of these at the moment. c. Each command line argument for (b) and (c) has less than 20 characters. d. There are at most 10 background jobs in a single test session. e. You can assume all user requests are "syntactically correct". Notes: o You need to learn a few C library calls by exploring the manual pages. Most of them are variants of what we discussed in lecture. o Instead of execl(), it is easier to make use of execv() in this case. Read up on execv() by "man-s2 execv". o Remember to use the waitpid() call in exercise 1. You only need a simple way to keep track of the background job PIDs. (hint: a simple array will do....). 0