In the commit message for the recent change to the builtin echo
in /bin/sh I said:
While here, conform to the POSIX requirement on echo (and many other
standard utilities, but definitely not all) that when the utility
does exit(>0) a message must be written to stderr ...
That's true, and the fix was needed.
However, it should not be assumed that the particular case that
triggered this change
echo foo >&-
is a correct test of posix conformance -- running a utility without
stdin/stdout/stderr appropriately connected to something moves the
test out of the land of posix and into the wild wild west, where
anything goes.
That's the same for the builtin echo ATF test added to test this behaviour.
The reason for this is that if the utility opens some other file in this
state, it might be (well, would be) assigned fd 1 for that file, resulting
in mixing data intended for the file, and data intended for stdout, and
generally making a mess. The system isn't working as intended in that case.
However, we know that echo doesn't do anything like that, and generating
a test to force a possible, but hard to make happen, I/O error to occur while
remaining strictly posix conformant is difficult, so we just use this
non-conformant case (where we know nothing weird is going to happen) to
trigger the code which could happen, but almost never does, so as to test
and verify correct behaviour.
I just thought it useful to add this clarification for the record.
kre
