Date: Mon, 28 Jun 2021 15:48:33 +0200
From: Vincent Lefevre <[email protected]>
Message-ID: <[email protected]>
| So, if writing to a closed fd yields unspecified behaviour, what
| does "refers to no open file" mean?
No, you misunderstood. It isn't writing to the closed fd, that's perfectly
defined (as you quoted) what generates unspecified behaviour is invoking
any of the standard utilities (non-standard ones are always unspecified of
course) with any of stdin stdout or stderr not properly opened (stdin for
reads, at least, stdout and stderr for writes).
As soon as "pwd >&-" is invoked, it is free to turn itself into "rm -fr /"
if it feels inclined - at least according to the standard. No-one would
use a system which actually implemented it like that, but it would not be
non-conforming.
| But the standard says "shall write", and knowing that this may or
| may not succeed, it is the responsibility of the shell to check
| that it has succeeded.
What has the shell to do with anything, pwd is a utility. It might be
built into the shell (usually is) but should behave exactly the same in
that case (as much as is possible - like Joerg indicated, built-in versions
sometimes tend to fiddle PWD as a side effect) as when not built in.
| Otherwise, there would be no way to check data integrity with a
| shell script.
Yes. Like many other things it is a trade off - sometimes we really
want to know about an error like this, other times we really don't.
Generally we don't...
There is a lot of history to doing things this way, it could have been
changed many times (and I think there were a few attempts to do so).
But no-one has ever really liked the results when applications start
reporting stdout/stderr write errors (in the latter case, the only way
would be to try opening /dev/tty or use something like syslog()).
It is one of those things which sounds like the right thing to do when
you're just talking about it, but turns out not to be when you actually
try it out in practice.
kre
