Date: Tue, 13 Jul 2021 10:18:02 +0100
From: "Geoff Clare via austin-group-l at The Open Group"
<[email protected]>
Message-ID: <20210713091802.GA28355@localhost>
Let's rearrange the order of this to make the issues more obvious.
We'll start with the EXIT STATUS section of cd:
82508 >0 Either the -e option or the -P option is not in effect, and an error
occurred.
82511 >1 Both the -e and the -P options are in effect, and an error occurred.
That is, if "an error occurred" cd must exit either >0 (1 or more) or >1
(2 or more) (depending on the -P -e options; that difference isn't
relevant here).
| Nothing here requires that the exit status is not zero if there was a
| write error on standard output.
OK, I can accept that, it is a reasonable position.
Now let's look at the EXIT status of pwd:
104924 >0 An error occurred.
There it is again, the exact same phrase. And it is your contention:
| This is quite different from pwd
Is it really? I'm afraid that (aside from the -Pe complication, which
I hope you aren't claiming makes a difference) that the wording looks
identical to me. If a write error on standard output is "an error [that]
occurred" surely both of them require an exit status >0. Otherwise, this
isn't treated as an error (or not an error required to be detected), and
both may exit 0. (nb: I am not claiming that an implementation of pwd
which decides to exit(1) if it detects a write error on standard output is
non-conforming, just that it is not required by the standard to do that.)
| where it is clear that the exit status can only be 0 if the working
| directory was successfully written to standard output (fd 1).
And where again is that clear ? I must be missing the wording.
And how is that different than what is in the cd STANDARD OUTPUT
requirements?
Does it say somewhere in the cd page (which I apparently missed) that the
write to standard output is inconsequential, and an error there should be
ignored? (which would be needed if somewhere else we find a requirement
that writes to standard output must be validated as having been successful).
Or alternatively is there some wording in the pwd page (again which I must
have missed) which says that the status of the write to standard output
must be verified? (which would be required if there is no general rule
that writes to standard output must be validated as having been successful).
Or, perhaps, is there some wording someplace else that says that writes to
standard output from cd and pwd are to be treated differently - either
explicitly naming those commands, or by some description of different types
or classes of commands where those two can be shown to fit into different
classes? I missed seeing that as well - but here the standard is BIG and
it would be easy to have missed some odd paragraph somewhere. If this is
what it is, it would be nice to xref this magic section from either the
command pages where it applies (clearly utilities which never write to
standard output at all are unconcerned with this) or if not from every page,
then at least from XCU 1.4.
Me, quoting you (|) quoting me (|>), quoting you (|>|):
| > | 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.
How exactly? Please cite the wording in the standard that says so.
Quoting the same text from pwd again isn't good enough, you're drawing a
conclusion, if that is all that you have. I want to see explicit text.
| Your refusal to acknowledge that fact is just making you look silly.
That's fine, if that's the worst that ever happens, I'll be happy.
| > It says we have to write to standard output, pwd (the version I use) does
| > that.
|
| No it doesn't.
Yes, it does. I have seen the code.
Or perhaps you're operating under the delusion that:
104869 DESCRIPTION
104870 The pwd utility shall write to standard output
actually says "shall successfully write to" ... It doesn't.
| You just agreed that "standard output" here means
| file descriptor 1.
No, I didn't. What I said was that the issue was irrelevant, as
where the output is to go isn't a relevant topic for this discussion
(it might be in some different discussion, if say, someone decided
that pwd should write its directory name to standard error instead).
| Your pwd writes to an internal buffer; it does
| not write to file descriptor 1.
I think you're operating under the mistaken impression that "my" pwd
(which I didn't write, though I have worked on - though not in this particular
area), that is, the one built into the NetBSD sh, uses stdio. It doesn't.
It has its own internal I/O routines, and I can assure you, that before
pwd exited, it did indeed issue a write() to fd 1 (or perhaps some other fd
to which what had previously been fd 1 had been moved .. that is, to
standard output, whatever fd number it happened to be at the time. In
simple uses it will be fd 1.) Exactly as required.
| 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.
Fine. Or actually, not really fine, except in the cases where there were
two competing versions where only one was wanted, and rather than simply
picking one or the other, a compromise was chosen, taking the best from
each. Simply deciding to change the world, because some small (self-selected)
group of people thought they knew better than everyone else is not fine.
| These included rules about error handling
Did it? Where's the text in the current standard (or you can even go back
to that ancient one, if it has since been deleted - but you would need to
explain why it was deleted in that case) where that is spelled out?
If I know what to look at, I can see if it says what you say it says, and
in particular, that the rules for cd and pwd are different for some reason.
| Let's be clear about the nature of this bug.
Let's ignore whether it is a bug or not. That's not (normally) what we
are here to discuss (there are odd cases where that issue does arise, but
here we're not discussing anything where that matters).
What is of concern here is what is the common behaviour of the implementations,
as that is the standard that the users experience, and what the document
produced here should reflect - whether you consider it a bug or not.
| 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.
Really? Given all this unexplained data loss, there must be a whole
raft of bug reports, and/or fixes, over the years, I assume that you
have evidence of that, or are you just guessing?
Remember that this issue arose because of a test environment sending output
to /dev/full - which is not something that typical applications usually do,
even on systems where it exists.
In practice, errors on standard output writes are either very rare, or
completely inconsequential (desired, or at least, anticipated - as in a
write to a pipe where the reader only takes some of the available data).
When they occur in other situations it is usually in a scenario where
so much is broken that no-one cares about some random command's output
(there are much more serious problems).
| It is time to put a stop to this disgraceful behaviour. NOW.
Whether or not that is true, that is not something that this group gets
to decide.
If you want to go file bug reports against android/solaris/aix/hp-ux/...
(and the various non-commercial systems as well) where they don't meet
your standards, then go ahead. That's the way to get potential bugs
evaluated, and perhaps fixed (and perhaps, eventually, that does become
the common behaviour, and can be standardised). Not by pretending that
the standards body is a legislature and mandating what you believe the
world should look like.
If you can't cope with separating your personal views from the requirements
of standards making, you should resign.
| If you don't fix this bug in the utilities you are a maintainer for,
| you are doing your users a great disservice.
I fix bugs that the user's report, after it is generally agreed that
it is indeed a real bug (we get plenty of "user misunderstanding" (let's
call it) "bug" reports filed - along with plenty of real ones).
So far, no-one has ever complained about any of this (even in the cases
where I'd also agree that doing exit(1) on a write error might be the
right thing to do).
But that's not the issue here, only what the standard says.
And I still do not see anywhere where it (explicitly) says what you claim
it says (nor where that can be deduced from other explicit statements that
exist). Do remember now that you need to find words to justify your
stance on both cd and pwd.
kre
