In flight.sh, I went to some considerable effort to preserve the original stdout by duping it to fd 5 and 4 before redirecting output to flight.sh.log. The idea was to be able to close flight.sh.log at the end and reopen the original stdout while waiting for a new command, leaving flight.sh.log available to be moved into run by saverun.
The idea was to allow subsequent output, if any, to go somewhere visible. In reality, on an installed Linux system, it usually goes to the console, which is almost never visible. On a standalone system, the output might go to one of the interactive log files, but there is very little output that would go there.
The downside to this is that the open file descriptor 4 is unnecessarily propagated to every program that is launched, which is just messy. Under QNX (arp-das), I could probably modify launch to close fd 4 (4>&-) because Launch is in flight.sh, but under monarch, Launch comes from load_exconfig.sh, so could possibly be used in other contexts where we want to propagate fd 4. OK, the chances of that are vanishingly small. Still, I see no value in maintaining this elaborate scheme.
In flight.sh, I went to some considerable effort to preserve the original stdout by duping it to fd 5 and 4 before redirecting output to flight.sh.log. The idea was to be able to close flight.sh.log at the end and reopen the original stdout while waiting for a new command, leaving flight.sh.log available to be moved into run by saverun.
The idea was to allow subsequent output, if any, to go somewhere visible. In reality, on an installed Linux system, it usually goes to the console, which is almost never visible. On a standalone system, the output might go to one of the interactive log files, but there is very little output that would go there.
The downside to this is that the open file descriptor 4 is unnecessarily propagated to every program that is launched, which is just messy. Under QNX (arp-das), I could probably modify launch to close fd 4 (4>&-) because Launch is in flight.sh, but under monarch, Launch comes from load_exconfig.sh, so could possibly be used in other contexts where we want to propagate fd 4. OK, the chances of that are vanishingly small. Still, I see no value in maintaining this elaborate scheme.