Op 27-04-18 om 17:33 schreef Herbert Xu:
Martijn Dekker <martijn@xxxxxxxx> wrote:$ dash -c '{ exec 8</dev/null; } 8<&-; : <&8 && echo "oops, still open"' Output: "oops, still open" Expected output: Bad file descriptorWell if you deconstruct the redirection it actually says 1) Close fd 8. 2) Open /dev/null and redirect to fd 8. The second part is done by exec and therefore must remain in the current shell execution environment. So dash's behaviour is compliant.
No, because step 1 doesn't merely close fd 8. It enters a curly braces block (a compound command) that locally closes fd 8 using a redirection, just like any other redirection would be local to that compound command. Thus, restoring the fd state when leaving that block must undo the effect of the 'exec'.
Note that dash already does this correctly if the '8<&-' is replaced by any other redirection such as '8>/dev/tty'.
POSIX 2.7 Redirection says: "Redirection is used to open and close files for the current shell execution environment [...] or for any command". Note that "any command" includes compound commands such as curly braces blocks.
However, POSIX also allows file descriptors greater than 3 to be closed in this case: If exec is specified without command or arguments, and any file descriptors with numbers greater than 2 are opened with associated redirection statements, it is unspecified whether those file descriptors remain open when the shell invokes another utility. Scripts concerned that child shells could misuse open file descriptors can always close them explicitly, as shown in one of the following examples. This allows for the behaviour of the other shells.
No, it's irrelevant. - M. -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
