Op 27-04-18 om 17:33 schreef Herbert Xu:
Martijn Dekker <mart...@inlv.org> wrote:
$ dash -c '{ exec 8</dev/null; } 8<&-; : <&8 && echo "oops, still open"'
Output: "oops, still open"
Expected output: Bad file descriptor


Well 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to