Robert Elz wrote, on 30 Jul 2021: > > Date: Thu, 29 Jul 2021 10:38:25 +0100 > From: "Geoff Clare via austin-group-l at The Open Group" > <[email protected]> > Message-ID: <20210729093825.GA7847@localhost> > > | Therefore, in the case of pwd, it is crystal clear that "Successful > | completion" means that it successfully completed the one action it is > | required to perform, and thus the exit status can only be 0 if the > | write to file descriptor 1 succeeded. > > No, you seem to have forgotten (or ignored) the CONSEQUENCE OF ERRORS > section ... > > 104925 CONSEQUENCES OF ERRORS > > 104926 If an error is detected, output shall not be written to standard > output, a diagnostic message shall > > 104927 be written to standard error, and the exit status is not zero.
You seem to have forgotten that this was already discussed, and as a result I submitted bug 1488 to modify the CONSEQUENCES OF ERRORS section so that it can't be misinterpreted the way you are doing. > | Good. So please go ahead and fix this bug in NetBSD sh. > > I did already, a while ago. That took about 30 seconds (including rebuilding, > but not testing - not that that was difficult either). Then I thought about > all the other built in commands which might need the same treatment, so I > decided on a more general solution, for all builtins. That took another > 30 seconds. Then when I was testing I came across cd and how it now behaved > (changing the directory, updating PWD, and still exiting 1 ... wrong). > > So then I thought I should look at all of the builtin commands, and what > they do, and how write errors need to be handled, and discovered I'd need > to add more syntax to our "build the builtins" mechanism, to indicate > whether stdout write errors need to be checked or not (that or go and > modify every builtin individually with special case code for each). > > At that point, I just decided this was all stupid - all to fix something > that doesn't really need fixing, as it is bothering no-one real. So I > abandoned all of those changes (none of it was ever committed). That's a shame. I'm sure those changes would be appreciated by your users. > | That's not my take on how we arrived in this situation. I think the > | POSIX.2 developers fully intended POSIX.2-1992 to require what I have > | been saying it required (and the current standard still requires). > > My guess, and that is all it is as I wasn't part of that, is that perhaps > some POSIX.2 developers did intend that (perhaps) but that other wiser > minds determined that the standard would fail balloting, or there would > end up being zero conforming systems if that was actually required, and > so wrote the language in a way that the "some developers" felt satisfied, > but which does not actually require anything of the kind. > > And that no specific text about any of this seems to exist anywhere (not > even in a rationale), or at least not that anyone has been able to find, > and I'm confident that there have been people looking, kind of supports > this result (if not the assumed process by which it was reached). > > | The reason the problem has not come to light until now is because the > | POSIX.3.2 developers (that's what the "test methods" draft standard > | for shell and utilities was originally called) classified the > | corresponding assertions as extended, and the test suite developers > | did not challenge that classification but instead just had their test > | suite give an "Untested" result code for those assertions. > > And you believe that all of that was just some kind of accident? Seriously? Yes, seriously. There have been other similar cases in the past where the shell and utilities test suite has been found not to be testing things it really should have been testing all along, because the relevant POSIX.3.2 assertions were misclassified as extended. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
