Date: Sat, 13 Apr 2024 16:10:26 -0400 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <32bd9e76-24bc-4206-aa8a-8bcc81722...@case.edu>
| File descriptors the user saves with exec redirections beyond [0-2] | are set to close-on-exec. POSIX makes that behavior unspecified, but | bash has always done it. It is the right way in general, it allows script fragments (like functions, loaded from external sources) to run external utilities without passing through file descriptors that they've never heard of, and so can't explicitly close. | Shells don't offer any standard way to modify the state of that flag, They don't. But in addition to fdflags our shell (not bash, and it has no coprocs, or anything similar) interprets the otherwise meaningless n>& n (or n<&n which is essentially the same thing) as a request to turn off close-on-exec for fd n. That can be a redirect on a specific command and applies (like any other redirect) just to that command (that command will have fd n open after it is exec'd), or it can be applied using "exec" to the fd in the shell itself (including in a later redirection in the same exec command which opens fd n originally, if the order of eval of the necessary bits ends up being defined - gets a bit messy when var expansions are needed). Apart from fdflags we don't have a mechanism to turn close-on-exec on again if it gets disabled that way, that's never seemed necessary. Perhaps you might have bash interpret it the same way - eventually perhaps it might become widespread enough to make it into the standard. And once there is a standard way to turn off close-on-exec maybe any shells which don't make that the default for fd's > 2 might see the advantages of doing it, and then perhaps that unspecified in the standard could go away too (sometime in the future). kre