On 23/04/2018 19:56, Martijn Dekker wrote:
$ dash -c '{ exec 8</dev/null; } 8<&-; : <&8 && echo "oops, still open"'
Output: "oops, still open"
Expected output: Bad file descriptor
Apparently, dash either fails to push the file descriptor onto the stack
at '} 8<&-', or fails to restore it.
Same bug with loops ending in "done 8<&-".
Confirmed in all dash versions down to 0.5.5.1.
What surprises me most is that dash has code written specifically to
keep the fd closed. dash would be smaller and simpler if it behaved the
way you expected and the way most other shells behave: just remove all
traces of REALLY_CLOSED.
FWIW, this also happens with n<&n which is ignored entirely. The
behaviour I would expect for that (and which I have implemented, but
which I am pretty sure has no chance anyway of getting into dash) is to
issue an error message if that fd is not open, and to save and later
restore the fd if it is open.
Test cases:
: 8<&8
Assuming fd 8 does not happen to be open already, bash and dash are the
only shells I've tested which accept this. ksh93, mksh, pdksh, yash,
zsh, bosh all reject it.
echo ok | { { exec 0<&-; } 0<&0; cat; }
Here, bash and dash are in agreement again, but this time they're not
alone: mksh and posh also cause an error message by leaving stdin
closed. The other shells restore stdin and print ok.
There is one more corner case on the subject of redirections, which
behaves unexpectedly in two shells in two different ways:
echo ok | cat 0>&0
Almost all shells are okay with this. The exceptions are bosh and yash:
yash rejects the redirection as fd 0 is not writeable, bosh appears to
mishandle all 0>* redirections, instead treating them as 1>*.
Cheers,
Harald van Dijk
