Robert Elz wrote, on 12 Jul 2021: > > Date: Mon, 12 Jul 2021 09:48:33 +0100 > From: "Geoff Clare via austin-group-l at The Open Group" > <austin-group-l@opengroup.org> > Message-ID: <20210712084833.GA31700@localhost> > > | Together these things constitute a requirement that pwd only exits > | with status 0 if it has successfully written an absolute pathname of > | the current working directory to file descriptor 1. > > No they don't
Of course they do. Your refusal to acknowledge that fact is just making you look silly. > It says we have to write to standard output, pwd (the version I use) does > that. No it doesn't. You just agreed that "standard output" here means file descriptor 1. Your pwd writes to an internal buffer; it does not write to file descriptor 1. > You believe that your view is the only thing that makes sense. But I know > it cannot be correct, because POSIX was documenting the standard behaviour, > of the implementations, the same as it still does (or should) and this was > not a case where there was any real deviation. No-one checked that kind of > thing, so to pretend (or require) that they did would not have been > appropriate. Hence any attempt to read the words as if it did cannot be > the correct reading. POSIX.2-1992 did not just document existing behaviour. It deliberately included various requirements that meant every implementation had to change in order to conform. These included rules about error handling that should have resulted in this ancient bug being fixed in the 1990s. Unfortunately, that didn't happen (for reasons we don't need to get into), with the possible exception of the GNU implementations. (I don't know whether they handled write errors properly pre-POSIX or were updated later.) Let's be clear about the nature of this bug. Considering all the utilities that are affected, and the length of time it has existed, it is a very serious bug that has undoubtedly caused many cases of data loss to go either unnoticed or unexplained, and will continue to do so until it is fixed. It is time to put a stop to this disgraceful behaviour. NOW. If you don't fix this bug in the utilities you are a maintainer for, you are doing your users a great disservice. > Let's abandon pwd for a while, and look at its close cousin, cd > > 82490 STDOUT > 82491 If a non-empty directory name from CDPATH is used, or if the operand > '-' is used, an absolute > 82492 pathname of the new working directory shall be written to the standard > output as follows: > > 82493 "%s\n", <new directory> > > (line numbers again from 202x-D2). > > That's very similar wording to that in pwd. > > 82512 CONSEQUENCES OF ERRORS > 82513 The working directory shall remain unchanged. > > If your view is correct, then if there is a write error writing the > pathname of the new working directory (and because of that wording, it > must be after a successful chdir() operation, or we would not know that > it is the new working directory) then the working directory remains > unchanged You clearly still haven't understood my argument, because that is not what my view would be in this case. This section requires that the working directory remains unchanged only if cd's exit status indicates that an error occurred. My argument all along been all about the exit status. Talking of which ... > And (some of EXIT STATUS) > > 82501 EXIT STATUS > 82502 The following exit values shall be returned: > > 82503 0 The current working directory was successfully changed and the value > of the PWD > 82504 environment variable was set correctly. Nothing here requires that the exit status is not zero if there was a write error on standard output. This is quite different from pwd where it is clear that the exit status can only be 0 if the working directory was successfully written to standard output (fd 1). -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
