Date: Thu, 8 Jul 2021 10:57:13 +0100
From: "Geoff Clare via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <20210708095713.GA24532@localhost>
| As Vincent pointed out, you are misinterpreting the standard. "If an
| error is detected, output shall not be written to standard output"
| obviously cannot apply to output that has already been written before
| the error occurs.
As I said in my reply to him, which didn't get cc'd to the list, because
I forgot to compensate for the absurd Reply-To that this list continues
to insist on inserting (along with the perhaps even worse From mangling),
an alternative interpretation to the one you (and he) believe applies is
that once output has been written to standard output, no errors may be
detected (they can occur, of course, but the code is not allowed to look
for them,not allowed to detect them).
| The whole
| point of that bit of rationale is that pwd should not write each
| component of the pathname individually as it works them out;
You'd think so, but that doesn't make a lot of sense, as if the code
is obtaining the path component by component (which is how implementations
used to work, before the getcwd() interface was invented (and actually
implemented otherwise than by popen("pwd", "r")) it gets the components
in the wrong order to write them one at a time as it proceeds - that is,
the final component comes first, then its parent, ... up to the root.
The only way to start at the beginning would be to do a recursive
descent through the whole filesystem (as "find" does for example) until
we happen to encounter the directory that is ".", which would be an
absurd implementation when the "scan .. for ., scan ../.. for .., ..."
method is so much simpler. And even with such a search, aside from "/"
at the start, we don't know we have anything correct until we have
everything.
| If you think about it, the alternative regarding partial output is worse.
| The alternative is that pwd is allowed to write partial output and exit
| with status 0, thus misleadingly indicating that the partial output it
| produced is the correct directory pathname.
That would be correct - but bug fixing is not the objective here, that
belongs elsewhere (in the bug reporting mechanisms for any implementation
that has a bug) - our task is to accurately describe what the actual
implementations do, so people using them can know what they are going to
encounter.
| Good quality implementations do what I said. Poor quality ones do not.
Once again, useless information. Which (or how many) existing implementations
are "good quality" and how many are "poor quality" ? That is, which of those
represents what the standard behaviour actually is?
nb: not what you believe it should be.
| Nice try to turn around an argument that actually applies to you, not to me.
| There is nothing in the standard to support your argument.
That is no surprise, and is my point. There is nothing in the standard.
You cannot quote anything to justify your belief of what should be done.
I cannot because I do not believe there is anything there to quote.
| In any case, as I said before, there is no need to involve the standard
| at all.
But that is what this list is all about. If the discussion is not about
what the standard says, then it doesn't belong here at all.
| The ancient behaviour is so obviously a bug that it beggars belief
| you cannot see it.
Why do you believe that? For purposes here, I don't care if it is
a bug or not, what I care about is what is the standard behaviour.
If not documenting bugs was the objective here, then half the nonsense
related to quoting in sh wouldn't exist, as how that works is also
obviously a bug. There's more. But none of that matters, as the
implementations implement the bug, so that is what the standard says
that they do. And is correct to do so.
Fixing implementation bugs is not the objective here. That happens
elsewhere. As long as the implementations contain this bug, we are
doing the wrong thing if we say that they do not (or should not).
Where something being a bug matters here, is where one (or perhaps
a couple of) implementation does something different than the others.
Then if we can describe that as a bug (and certainly if that system's
implementors admit it) we can simply ignore that, and expect it to get
fixed. But when (almost) everyone implements the bug, that bug is
the standard. We don't necessarily need to require it be implemented
(as these days is being done with sh quoting - some of the more bizarre
behaviour is unspecified, which allows implementors to fix things
as much as they can allowing for backward compat issues) but we cannot
just pretend that there is no bug because we wish it were so.
In this case there is no need to do anything like that, aside from that
"consequences of errors" section, which probably should be fixed, and which
applies only to pwd, not all the other utilities, there is nothing to
prohibit implementations from detecting the error if they want. But we
just must not pretend that happens unless the vast majority of implementations
actually implement that. And so far I see no evidence that they do.
Then, if it ever happens that such evidence appears, and detecting output
errors is so common that we can regard it as standard behaviour, then we
would need explicit language in the standard if we want that to be a
requirement, and I am fairly confident now that currently no such language
exists, or someone would have quoted it already.
kre
