The following pseudo-code was given (in class) for the creation of a "job" constructed from a list of commands that are to be connected together by pipes for cmd in cmds if there is a next cmd pipe(new_fds) fork if child if there is a previous cmd dup2 (old_fds [0], 0) close (old fds [0]) close(old_fds [1]) if there is a next cmd close(new_fds [0]) dup2 (new_fds[1], 1) close(new fds[1]) exec cmd || die else if there is a previous cmd close(old_fds [0]) close(old_fds [1]) if there is a next cmd old_fds = new_fds if there are multiple cmds close (old fds [0]) close(old fds[1]) (a) In a sense it is a complete solution to the stated task but something is missing if this code is to used embedded in an application that issues further jobs. What is missing? What problem does it cause? What is the fix? (b) Inspecting the code for the child, there is a sequence of statements for a previous command existing and another sequence for a next command existing, but the two sequences are different (dup2, close, close) vs (close, dup2, close). Is there a good reason for this difference? Ex plain your answer. (c) Looking again at the same parts of code, does dup2(old_fds[0], 0) close(old_fds[0]) have to be done in this order or can they be swapped? Explain your answer. (d) Consider the final "if statement" in the listing. Why is there no need to close the file descriptors if there is only a single command? (e) Consider the fork. At that point both the parent and the child have the same code that implements this pseudo-code. What stops the child process executing the code to the point where it - itself - forks another instance of this process with the same code (and, of course, so on ellipsis)? (f) The above could be construed as saying "the child never forks". This isn't true - why? The following pseudo-code was given (in class) for the creation of a "job" constructed from a list of commands that are to be connected together by pipes for cmd in cmds if there is a next cmd pipe(new_fds) fork if child if there is a previous cmd dup2 (old_fds [0], 0) close (old fds [0]) close(old_fds [1]) if there is a next cmd close(new_fds [0]) dup2 (new_fds[1], 1) close(new fds[1]) exec cmd || die else if there is a previous cmd close(old_fds [0]) close(old_fds [1]) if there is a next cmd old_fds = new_fds if there are multiple cmds close (old fds [0]) close(old fds[1]) (a) In a sense it is a complete solution to the stated task but something is missing if this code is to used embedded in an application that issues further jobs. What is missing? What problem does it cause? What is the fix? (b) Inspecting the code for the child, there is a sequence of statements for a previous command existing and another sequence for a next command existing, but the two sequences are different (dup2, close, close) vs (close, dup2, close). Is there a good reason for this difference? Ex plain your answer. (c) Looking again at the same parts of code, does dup2(old_fds[0], 0) close(old_fds[0]) have to be done in this order or can they be swapped? Explain your answer. (d) Consider the final "if statement" in the listing. Why is there no need to close the file descriptors if there is only a single command? (e) Consider the fork. At that point both the parent and the child have the same code that implements this pseudo-code. What stops the child process executing the code to the point where it - itself - forks another instance of this process with the same code (and, of course, so on ellipsis)? (f) The above could be construed as saying "the child never forks". This isn't true - why