On 11/06/2019 09:39, Geoff Clare wrote:
Harald van Dijk <[email protected]> wrote, on 10 Jun 2019:
On 10/06/2019 09:46, Austin Group Bug Tracker wrote:
----------------------------------------------------------------------
(0004413) geoffclare (manager) - 2019-06-10 08:46
http://austingroupbugs.net/view.php?id=760#c4413
----------------------------------------------------------------------
The changes arising from this bug were applied in POSIX.1-2008 TC2, so this
is not the right place to request further changes. (All of the bugs tagged
tc2-2008 should have been closed some time ago to prevent this situation
arising.)
Re: http://austingroupbugs.net/view.php?id=760#c4411 <&0 is a no-op, so it's
unclear whether it counts as
"explicit redirection of standard input".
In almost all shells, <&0 is not a no-op. It is a check that stdin is open.
It will cause an immediate error without executing any command otherwise. By
my reading of the standard, this is the required behaviour and it is a
(minor) bug for a few shells to implement it as a no-op.
I would say the standard is silent on this. 2.7.5 says <&word "shall
duplicate one input file descriptor from another, or shall close one".
The use of "another" here implies they are different file descriptors.
That is a good point and applies to <&0 when stdin is open. All the more
reason why you cannot say that <&0 is a no-op.
It does not apply when word refers to a closed file descriptor though:
exec 3>&-
exec 4>&3
Here, it is clear that no file descriptor is duplicated or closed. In
particular, if fd 4 was already open, it remains open. This is not
covered by the sentence you quote, it is covered by "if the digits in
word do not represent a file descriptor already open for input, a
redirection error shall result" instead. Same for <&0 when stdin is
closed. The word "another" is not used there.
Cheers,
Harald van Dijk
