I need this solved with all of the steps shown and explained in full detail. If so I will give you the best rating. I have provided makefile below. I need to the multitasking commandar done NOTHING ELSE. If you need anything else please tell me. This assignment is in C.

basic idea:

1. The Boring Commander: This software runs a sequence of pre-programmed commands, outputting results and statistics as it goes. The commands the Boring Commander runs are simple and do not involve side-effects between commands. The Boring Commander should be compiled into an executable named boring.

2. The Custom Commander: This software opens a file, custom.txt, and runs the commands in order. Unlike the Boring Commander, the Custom Commander supports side-effects (like changing directories). The Custom Commander should be compiled into an executable named custom.

3. The Multitasking Commander: The Multitasking Commander supports the notion of background processes. It opens a file, multi.txt, to determine what commands to run. It also takes command line parameters that indicate what lines should be run in the background. The Multitasking Commander should be compiled into an executable named multi. This project will allow students to learn about process creation, termination, and resource usage in the Linux operating system. All coding is to be done in the C programming language. We highly recommend implementing or testing the project on the Ubuntu virtual machine you created in Project 0. Projects that do not compile or run correctly on the Ubuntu virtual machines may be penalized. These projects will be graded in bulk with some scripting support, so it is important that the associated Makefile1 produces files with the specified executable names and that each read the specified file for commands. Students will want to ensure they can build and run the code from the command line. We now describe the three commanders in detail, along with their expected outputs.

THIS IS WHAT I NEED: I NEED YOU TO CREATE THE MULTITASKING COMMANDER using multi.c multi-helper1.c, multi.txt, etc. It must follow the guidelines given below

Makefile:

Phase 3: The Multitasking Commander The Multitasking Commander's main source code file should be named multi and you should extend your previous Makefile to compile the Multitasking Commander into the executable multi. If you have other source code files, they should be named with multi as the prefix (e.g., multi, multi-helper1.c). The Multitasking Commander will do everything the Custom Commander does, but will add two new bility to run background commands and the ability to print running jobs. To implement background commands, the Multitasking Commander will read the command-line argu- ments to determine which lines in multi.txt should be run in the background. To do so, it will loop through the values in the ARGV array in int main, parse each to an integer see the atoi function), and store those line numbers. When it reads the associated line number from multi.txt, it will run it in the background. As a result, there may be multiple child processes active at once, even while multi is reading an additional command. Moreover, a background task can terminate at any time. In this case, multi should display a message that the particular task has terminated, and it should follow that message with the statistics about the command of that task. When a task is run in background, multi should not block until the child process completes. Instead, it should read the next line in the file and process that command. In addition to the built-in commands of custom, multi must also handle the cproclist command, which lists all background processes currently active. Note that output from background commands that is directed to the terminal window may intermingle with the output of other commands and with the output from your multi program itself. That is perfectly fine. Example Input File The following is an example multi.txt that will produce the output indicated: sleep 10 ls -alh sleep 3 cproclist cpwd Example Custom Commander Output shepardonormandy :"> ./multi 1 3 Running command: sleep 10 Background: ID [O]: sleep 10 Running command: ls -alh total 132 drwxr-xr-x 33 root drwxr-xr-x 24 root drwxr-xr-x 3 shepard root root root 4096 Oct 5 13:40 4096 Dec 6 09:20 .. 4096 Aug 31 2016 shepard Example Custom Commander Output shepard@normandy: > ./multi 13 Running command: sleep 10 Background: ID [O]: sleep 10 Running command: ls -alh total 132 drwxr-xr-x 33 root drwxr-xr-x 24 root drwxr-xr-x 3 shepard root root root 4096 Oct 5 13:40 . 4096 Dec 6 09:20 .. 4096 Aug 31 2016 shepard -- Statistics --- Elapsed time: 5 milliseconds Page Faults: 0 Page Faults (reclaimed): 0 -- End of Statistics -- Running command: sleep 3 Background: ID [1]: sleep 3 Running command: cproclist -- Background Processes -- [O] sleep 10 [1] sleep 3 Running command: cpwd Current directory: / [Only output from cpwd] -- Job Complete [1: sleep 3] -- Process ID: 12345 -- Statistics --- Elapsed time: 3000 milliseconds Page Faults: 0 Page Faults (reclaimed): 0 -- End of Statistics -- -- Job Complete [O: sleep 10] -- Process ID: 12340 -- Statistics --- Elapsed time: 10000 milliseconds Page Faults: 0 Page Faults (reclaimed): 0 -- End of Statistics -- shepardonormandy :"> If the file processing completes before all the background tasks have completed, then multi program should wait for those tasks to be completed. As part of the write-up describing your program, you must explain how you keep track of outstanding processes in multi-i.e., the data structures and algorithms for maintain information about outstanding commands that have not been completed. Helpful hints The following two functions may be useful: vait3) - lets you wait for any child process, returns rusage statistics wait40 - lets you wait for a specific child process, returns rusage statistics Either of these functions can be called with the WNOHANG option, which causes the wait() function to not block but rather return with an error code (e.g., "nobody is ready to be waited on yet"). A suggested approach to handling background tasks is as follows. After forking a child process to invoke a background command, go into a loop using wait 3 (WNOHANG) to wait for any child to finish. If wait3 returns information about a child process that has finished, print its statistics and repeat the loop. However, if wait3() indicates that no child process has finished lately, exit the loop and read the file for the next command. In the case that a command is not a background process, then you should use a wait3 loop without the WNOHANG argument. This will pick up any previous background commands that may have completed. Once the non-background task has been waited for, loop again using wait3(WNOHANG) to pick up any remaining tasks that have finished. When wait3(WNOHANG) returns with an error, then read the file for the next command. Checkpoint Contributions Students must submit work that demonstrates substantial progress towards completing the project on the checkpoint date. Substantial progress is judged at the discretion of the grader to allow students flexibility in prioritizing their efforts. However, as an example, any assignment in which the first phase is completed and has a partial implementation of the second phase will be considered as making substantial progress Projects that fail to submit a checkpoint demonstrating significant progress will incur a 10% penalty during final project grading. Deliverables and Grading When submitting your project, please include the following: All of the files containing the code for all parts of the assignment. One file called Makefile that can be used by the make command for building the three executable programs. It should support the "make clean" command, "make all" and make each of the three programs individually. The test custom.txt and multi.txt files that you use to convince yourself and others) that your programs actually work. Output from your tests. A document called README.txt explaining your project and anything that you feel the instructor should know when grading the project. In particular, describe the data structure and algorithm you used to p track of background jobs. Also, explain how you tested your programs. Only plaintext write-ups are accepted. Deliverables and Grading When submitting your project, please include the following: . All of the files containing the code for all parts of the assignment. One file called Makefile that can be used by the make command for building the three executable programs. It should support the "make clean" command, "make all" and make each of the three programs individually. The test custom.txt and multi.txt files that you use to convince yourself and others) that your programs actually work. Output from your tests. A document called README.txt explaining your project and anything that you feel the instructor should know when grading the project. In particular, describe the data structure and algorithm you used to keep track of background jobs. Also, explain how you tested your programs. Only plaintext write-ups are accepted. Please compress all the files together as a single .zip archive for submission. As with all projects, please only standard zip files for compression; .rar, .7z, and other custom file formats will not be accepted The project programming is only a portion of the project. Students should use the following checklist in turning in their projects to avoid forgetting any deliverables: 1. Sign up for a project partner or have one assigned (URL: https://ia.wpi.edu/ca3013-valls/ request_teammate.php), 2. Submit the project code and documentation via Instruct Assist (URL: https://ia.wpi.edu/cs3013-walls files.php) 3. Complete your Partner Evaluation (URL: https://ia.wpi.edu/cs3013-walls/evals.php), and 4. Schedule your Project Demonstration (URL: https://ia.wpi.edu/cs3013-walls/demos.php), which may be posted slightly after the submission deadline. A grading rubric has been provided at the end of this specification to give you a guide for how the project will be graded. No points can be earned for a task that has a prerequisite unless that prerequisite is working well enough to support the dependent task. Students will receive a scanned markup of this rubric as part of their project grading feedback. Groups must schedule an appointment to demonstrate their project to the teaching assistants. Groups that fail to demonstrate their project will not receive credit for the project. If a group member fails to attend his or her scheduled demonstration time slot, he or she will receive a 10 point reduction on his or her project grade. During the demonstrations, the TAs will be evaluating the contributions of group members. We will use this evaluation, along with partner evaluations, to determine contributions. If contributions are not equal, underentributin students may be nenaliny all: boring custom boring: boring.c gcc -o boring boring.c custom: custom.c gcc -o custom custom.c clean: rm boring custom Phase 3: The Multitasking Commander The Multitasking Commander's main source code file should be named multi and you should extend your previous Makefile to compile the Multitasking Commander into the executable multi. If you have other source code files, they should be named with multi as the prefix (e.g., multi, multi-helper1.c). The Multitasking Commander will do everything the Custom Commander does, but will add two new bility to run background commands and the ability to print running jobs. To implement background commands, the Multitasking Commander will read the command-line argu- ments to determine which lines in multi.txt should be run in the background. To do so, it will loop through the values in the ARGV array in int main, parse each to an integer see the atoi function), and store those line numbers. When it reads the associated line number from multi.txt, it will run it in the background. As a result, there may be multiple child processes active at once, even while multi is reading an additional command. Moreover, a background task can terminate at any time. In this case, multi should display a message that the particular task has terminated, and it should follow that message with the statistics about the command of that task. When a task is run in background, multi should not block until the child process completes. Instead, it should read the next line in the file and process that command. In addition to the built-in commands of custom, multi must also handle the cproclist command, which lists all background processes currently active. Note that output from background commands that is directed to the terminal window may intermingle with the output of other commands and with the output from your multi program itself. That is perfectly fine. Example Input File The following is an example multi.txt that will produce the output indicated: sleep 10 ls -alh sleep 3 cproclist cpwd Example Custom Commander Output shepardonormandy :"> ./multi 1 3 Running command: sleep 10 Background: ID [O]: sleep 10 Running command: ls -alh total 132 drwxr-xr-x 33 root drwxr-xr-x 24 root drwxr-xr-x 3 shepard root root root 4096 Oct 5 13:40 4096 Dec 6 09:20 .. 4096 Aug 31 2016 shepard Example Custom Commander Output shepard@normandy: > ./multi 13 Running command: sleep 10 Background: ID [O]: sleep 10 Running command: ls -alh total 132 drwxr-xr-x 33 root drwxr-xr-x 24 root drwxr-xr-x 3 shepard root root root 4096 Oct 5 13:40 . 4096 Dec 6 09:20 .. 4096 Aug 31 2016 shepard -- Statistics --- Elapsed time: 5 milliseconds Page Faults: 0 Page Faults (reclaimed): 0 -- End of Statistics -- Running command: sleep 3 Background: ID [1]: sleep 3 Running command: cproclist -- Background Processes -- [O] sleep 10 [1] sleep 3 Running command: cpwd Current directory: / [Only output from cpwd] -- Job Complete [1: sleep 3] -- Process ID: 12345 -- Statistics --- Elapsed time: 3000 milliseconds Page Faults: 0 Page Faults (reclaimed): 0 -- End of Statistics -- -- Job Complete [O: sleep 10] -- Process ID: 12340 -- Statistics --- Elapsed time: 10000 milliseconds Page Faults: 0 Page Faults (reclaimed): 0 -- End of Statistics -- shepardonormandy :"> If the file processing completes before all the background tasks have completed, then multi program should wait for those tasks to be completed. As part of the write-up describing your program, you must explain how you keep track of outstanding processes in multi-i.e., the data structures and algorithms for maintain information about outstanding commands that have not been completed. Helpful hints The following two functions may be useful: vait3) - lets you wait for any child process, returns rusage statistics wait40 - lets you wait for a specific child process, returns rusage statistics Either of these functions can be called with the WNOHANG option, which causes the wait() function to not block but rather return with an error code (e.g., "nobody is ready to be waited on yet"). A suggested approach to handling background tasks is as follows. After forking a child process to invoke a background command, go into a loop using wait 3 (WNOHANG) to wait for any child to finish. If wait3 returns information about a child process that has finished, print its statistics and repeat the loop. However, if wait3() indicates that no child process has finished lately, exit the loop and read the file for the next command. In the case that a command is not a background process, then you should use a wait3 loop without the WNOHANG argument. This will pick up any previous background commands that may have completed. Once the non-background task has been waited for, loop again using wait3(WNOHANG) to pick up any remaining tasks that have finished. When wait3(WNOHANG) returns with an error, then read the file for the next command. Checkpoint Contributions Students must submit work that demonstrates substantial progress towards completing the project on the checkpoint date. Substantial progress is judged at the discretion of the grader to allow students flexibility in prioritizing their efforts. However, as an example, any assignment in which the first phase is completed and has a partial implementation of the second phase will be considered as making substantial progress Projects that fail to submit a checkpoint demonstrating significant progress will incur a 10% penalty during final project grading. Deliverables and Grading When submitting your project, please include the following: All of the files containing the code for all parts of the assignment. One file called Makefile that can be used by the make command for building the three executable programs. It should support the "make clean" command, "make all" and make each of the three programs individually. The test custom.txt and multi.txt files that you use to convince yourself and others) that your programs actually work. Output from your tests. A document called README.txt explaining your project and anything that you feel the instructor should know when grading the project. In particular, describe the data structure and algorithm you used to p track of background jobs. Also, explain how you tested your programs. Only plaintext write-ups are accepted. Deliverables and Grading When submitting your project, please include the following: . All of the files containing the code for all parts of the assignment. One file called Makefile that can be used by the make command for building the three executable programs. It should support the "make clean" command, "make all" and make each of the three programs individually. The test custom.txt and multi.txt files that you use to convince yourself and others) that your programs actually work. Output from your tests. A document called README.txt explaining your project and anything that you feel the instructor should know when grading the project. In particular, describe the data structure and algorithm you used to keep track of background jobs. Also, explain how you tested your programs. Only plaintext write-ups are accepted. Please compress all the files together as a single .zip archive for submission. As with all projects, please only standard zip files for compression; .rar, .7z, and other custom file formats will not be accepted The project programming is only a portion of the project. Students should use the following checklist in turning in their projects to avoid forgetting any deliverables: 1. Sign up for a project partner or have one assigned (URL: https://ia.wpi.edu/ca3013-valls/ request_teammate.php), 2. Submit the project code and documentation via Instruct Assist (URL: https://ia.wpi.edu/cs3013-walls files.php) 3. Complete your Partner Evaluation (URL: https://ia.wpi.edu/cs3013-walls/evals.php), and 4. Schedule your Project Demonstration (URL: https://ia.wpi.edu/cs3013-walls/demos.php), which may be posted slightly after the submission deadline. A grading rubric has been provided at the end of this specification to give you a guide for how the project will be graded. No points can be earned for a task that has a prerequisite unless that prerequisite is working well enough to support the dependent task. Students will receive a scanned markup of this rubric as part of their project grading feedback. Groups must schedule an appointment to demonstrate their project to the teaching assistants. Groups that fail to demonstrate their project will not receive credit for the project. If a group member fails to attend his or her scheduled demonstration time slot, he or she will receive a 10 point reduction on his or her project grade. During the demonstrations, the TAs will be evaluating the contributions of group members. We will use this evaluation, along with partner evaluations, to determine contributions. If contributions are not equal, underentributin students may be nenaliny all: boring custom boring: boring.c gcc -o boring boring.c custom: custom.c gcc -o custom custom.c clean: rm boring custom