In this assignment, you will implement a command line interpreter (CLI) or, as it is more commonly known, a shell. The shell should operate in this basic way: when you type in a command (in response to its prompt), the shell creates a child process that executes the command you entered and then prompts for more user input when it has finished The shells you implement will be similar to, but simpler than, the one you run every day in Unix. If you don't know what shell you are running, it's probably bash. One thing you should do on your own time is learn more about your shell, by reading the man pages or other online materials The shell is very simple (conceptually): it runs in a while loop, repeatedly asking for input to tell it what command to execute. It then executes that command. The loop continues indefinitely, until the user types the built-in command exit, at which point it exits. That's it! For reading lines of input, you should use getline (). This allows you to obtain arbitrarily long input lines with ease. Generally, the shell will be run in interactive mode, where the user types a command (one at a time) and the shell acts on it. However, your shell will also support batch mode, in which the shell is given an input file of commands; in this case, the shell should not read user input (from stdin) but rather from this file to get the commands to execute In either mode, if you hit the end-of-file marker (EOF), you should call exit(0) and exit To parse the input line into constituent pieces, you might want to use strtok) (or, if doing nested tokenization, use strtok r()). Read the man page (carefully) for more details To execute commands, look into fork), execvp(), and waitpid). See the man pages foir these functions, and also read the relevant book chapter and example program for a brief overview You will note that there are a variety of commands in the exec family; for this project, you must use execvp. You should not use the system() library function call to run a command. Remember that if execvp) is successful, it will not return; if it does return, there was an error (e.g., the command does not exist). The most challenging part is getting the arguments correctly specified 2.1 Interactive Mode In interactive mode, your shell will display the prompt mysh$. The users of the shell will type commands after the prompt that will be interpreted by your shell. Unless explicitly indicated by the job separator, the jobs contained in the command are executed sequentially and in the order presented. The prompt is returned when all of the jobs are completed. An example usage of the nteract l would be (input is Highlighted) [grace@CS441 ]$./mysh mysh$ date Wed Sept 17 10:00:00 CDT 2017 mysh$ pwd /home/grace/project2/part2 mysh$ 1s tests file1.txt file.txt 2.2 Batch Mode In batch mode, the shel is started by specifying one or more batch files to the shell on the command line. The batch file contains a list of commands (one per line) that should be executed In batch mode, you must not display a prompt In the case of multiple batch files, the files should be executed sequentially in the order they are presented on the command line. If there are background jobs in multiple batch files (say the first and second) then they may be running concurrently. The shell will need to wait on al of those background processes to finish before exiting the shell (once all batch files have finished being processed). The job totals displayed when the shell is exiting will represent all of the jobs started by all of the batch files. See the Section 2.4 for more details Most batch files will not contain the exit command, but ill terminate by reaching the end-of- file. If the shell encounters the exit command in a batch file it must skip the rest of that batch file, and also skip the remaining batch files that have not yet been processed. The exit command will start to shutdown the shel waiting for any outstanding background processes to complete before displaying the shell job statistics and terminating. See the Section 2.5.5 for more details. An example of the batch shell interaction is below: [grace@CS441 ]$ cat tests/file1.txt date ls tests [grace@CS441 /mysh tests/file1.txt Wed Sept 17 10:00:00 CDT 2017 /home/grace/project2/part2 file1.txt file.txt Total number of jobs Total number of jobs in history3 Total number of jobs in background - 0 [grace@CS441 ]$./mysh tests/file1.txt tests/file1.txt Wed Sept 17 10:00:00 CDT 2017 /home/grace/project2/part2 file1.txt file.txt Wed Sept 17 10:00:00 CDT 2017 /home/grace/project2/part2 file1.txt file.txt Total number of jobs Total number of jobs in history- 6 Total number of jobs in background - 0 [grace@CS441 ]$ 2.3 Sequential Execution of Multiple Jobs In both interactive and batch mode, more than one job can be specified on a single command line. To separate jobs on a command line a semi-colonmust be used at the end of the job Each job is executed in sequential order, and the prompt is only shown when all of the jobs have completed in the interactive shell (no prompt is shown when in batch mode). For example: mysh$ date Wed Sept 17 10:00:00 CDT 2017 myshS date; Wed Sept 17 10:00:00 CDT 2017 myshS date; pwd; ls tests Wed Sept 17 10:00:00 CDT 2017 /home/grace/project2/part2 file1.txt file.txt myshS 2.4 Concurrent Execution of Multiple Jobs In both interactive and batch mode, a job can be run "in the background." This means that a job can be processing while the user is entering more commands or other jobs are running. Background processing can also be thought of as concurrent processing since more than one process is active at the same time Jobs that wish to be run in the background are followed by an ampersand&instead of a semicolon [;]. Any executable can be run in the background, not just those represented in the examples. A user can check on the state of background jobs using the jobs built-in command. The jobs command will display the state of any jobs running the background. Backgrounded jobs can be in one of two states visible to the user: Running or Done. When there are no jobs running in the background then nothing is printed. Backgrounded jobs that have completed will be marked as Done and can be cleaned up only after the user calls the jobs command or at exit As an example, the following sequential command executes in 12 seconds, and returns a prompt when al three jobs have finished myshs sleep 4 sleep 5 sleep 3 If we execute these commands in the background then they will all finish one second after each other taking about 5 seconds to complete all three jobs. The prompt is returned immediately to the user. The jobs command displays the job number, job state, and full command (with the argument set) for each background job. Once a Done job has been displayed with the job:s command then it may be removed from future listings mysh$ jobs mysh$ sleep 4 & /bin/sleep 5 & /bin/sleep 3 & /bin/date& Wed Sept 17 10:00:00 CDT 2017 mysh$ jobs Running sleep 4 [2Running /bin/sleep 5 [3] Running /bin/sleep 3 4] Done mysh$ jobs /bin/date Done sleep 4 2Rnning /bin/sleep 5 [3] Done mysh$ jobs [2 Done myshS jobs mysh$ /bin/sleep 3 /bin/sleep 5 2.5 Builtin Commands Our shell will support the following builtin commands: jobs, history, wait, fg, exit. Any other command that the user might type into our shell should be interpreted as an executable (a.k.a., binary) to launch (via execvp) WARNING!!! Do not try to implement your own ls or sleep or echo commands! Those are programs provided by the UNIX environment. Additionally, do not limit your she to only accepting the binaries listed in the examples. The user may supply any binary name The builtin commands cannot be run in the background in our shell. The builtin commands may appear in a sequence of jobs as in the following example: mysh$ sleep 4 & jobs sleep 3 2.5.1 Jobs In both modes of execution, your shell will support the ability to display a list of the jobs that are currently in the background. For more details on how this should be displayed see section 2.4 and the examples throughout this document 2.5.2 Historv In both modes of execution, your shell will support the ability to display the full history of job commands typed into the shell. The history command displays all of the jobs executed by the shell (including the erroneous ones) from the earliest command to the latest command. For each job, it will display the job number and the full command (with the argument set). If the job was a background job then the k' symbol is displayed after the argument set. The history display will include the builtin commands 2.5.3Wait In both modes of execution, your shell will support the ability to wait for all currently back- grounded jobs to complete. If there are no backgrounded jobs, then the command returns imme- diately. This command requires that you properly manage your processes and keep track of your 2.5.4 Foreground (fg) In both modes of execution, your shell will support the ability to wait for a specific currently backgrounded job. If there are no backgrounded jobs, then the command returns an error. fg takes zero or one arguments. If there are zero arguments, then the latest backgrounded process is brought into the foreground and will not return until the job has completed. If there is an argument, it will be the job id of the job to bring into the foreground, as listed by the jobs command. If the job has already completed, an error message telling the user that the job has completed is produced. The jobs command output should treat this as the user knowing about this particular job completing, and should not display it in subsequent jobs output 2.5.5 Exiting the Shell In both interactive and batch mode, your shell terminates when it sees the exit command or reaches the end of the input stream (i.e., the end of the batch file or the user types 'Ctrl-D) If a background process is still running when the shell exits then the shell should wait for that process to complete before exiting. In this case, your shell should print a message indicating the number of jobs the shell is waiting on when given the exit command Before the shell exits, the shell should print a count of the total number of jobs that were executed (excluding builtin commands), the total number of jobs in the history (including builtin commands), and the total number of jobs that were executed in the backgroun. redirects stdout to the specified file. For example, if you want to redirect the output of a program that normally prints to standard output, you can do the following mysh$ ./hello Hello, World! mysh$ ./hello > outfile mysh$ cat outfile Hello, World! If you want to redirect a file as standard input to a program, you can do the following: mysh$ ./hello_name Hello, World! What is vour name? am Hello, Sam! mysh$ cat infile am mysh$./hello_name . redirects stdout to the specified file. For example, if you want to redirect the output of a program that normally prints to standard output, you can do the following mysh$ ./hello Hello, World! mysh$ ./hello > outfile mysh$ cat outfile Hello, World! If you want to redirect a file as standard input to a program, you can do the following: mysh$ ./hello_name Hello, World! What is vour name? am Hello, Sam! mysh$ cat infile am mysh$./hello_name