Date: Mon, 28 Jun 2021 13:26:48 +0200
From: "Joerg Schilling via austin-group-l at The Open Group"
<[email protected]>
Message-ID: <20210628112648.qkgag%[email protected]>
Several messages to which to reply ... but I'll start with the
easy ones.
| It could be argued that setting up PWD is the main task for pwd
As has been said before, almost anything can be argued - but this one
would definitely fail. Utilities (other than perhaps the few that are
only possible as shell builtins) cannot possibly be expected to set
shell variables.
See how well /bin/pwd does at setting PWD in your shell?
There's definitely nothing to be gained from that argument.
[email protected] said:
| On the zsh mailing list, where the issue was initially brought up by
| Vincent, there was also the mention that EBADF error was explicitly
| ignore as a special case, as some systems have or used to have
| non-usable /dev/null,
Weird, just out of interest, which are those? And do any of them
claim to be (any facsimile of) posix conformant?
| so users were using >&- instead to silence output.
| If stdout is closed, one could argue the user explicitly wants the
| output to be discarded.
if a utility is invoked with any of stdin/out/err closed then what happens
is very explicitly unspecified in POSIX. My guess is that that is largely
because if the utility then opens a file it will be given a fd that
corresponds to the (or one of the) closed stdin/out/err streams, and truly
bizarre things are likely to happen - but that kind of issue is not stated
as the reason, you simply get unspecified behaviour if a utility is
started that way.
So none of your examples using >&- are useful here at all (even though
they are a very simple way to force an error). Nor would it be useful
to try
cmd 1</dev/null
or something (leave fd 1, stdout, open, but read only) - that's also
unspecified.
We need a real error, in a standards conforming environment, which is why
EPIPE is the easiest to make happen.
(If we want to be more certain that the pipe is really closed by the time
a write to it happens, the test cases should probably be more like
{ sleep 1; cmd } | (exit 0)
otherwise cmd might have written to the pipe (successfully) before the
exit happens.
[email protected] (really Geoff Clare) said:
| The error occurred, and because of it the utility did not do what it is
| supposed to do.
That's debatable. The outcome was not what was desired, but the utility
did exactly what was required of it, it determined (one assumes for this
purpose, where this fails truly is an error to be reported) the current
working directory and printed it, then exited, with no errors reported to
it.
You might prefer that it "fflush(stdout); if (ferror(stdout)) ..." but
there's nothing explicit in the standard that says that it has to do that.
The rest of your paragraph then becomes irrelevant.
[email protected] (always Geoff unless otherwise stated) said:
| If write() fails with EPIPE then yes I would expect pwd to write
| a diagnostic message and exit with non-zero status.
Are you talking explicitly about pwd, or about utilities that are designed
to write to stdout in general?
If the former, if there's something specific about pwd that requires this,
other than just that this is what you'd like, then where in the standard
is that stated?
If in general, then forget it - the users would lynch you (you'd probably
suicide first) if you successfully caused that to happen.
[email protected] said:
| You are talking about pre-POSIX tradition. The rules in POSIX.2 should have
| put an end to that ancient dodgy behaviour when systems were updated to
| conform to POSIX.
Do you have some evidence that they did? My guess is that no-one would
even consider making that change, as nice as it might be for some programs
(those might be changed - just because it seems weird otherwise - and pwd
could perhaps be one of those) in general it would be a disaster.
Not happening.
kre
