Date: Tue, 29 Jun 2021 01:52:32 +0200
From: Vincent Lefevre <[email protected]>
Message-ID: <[email protected]>
| Where is this written (at least for the particular case of builtins)?
Philip Guenther supplied the text - there's nothing special about
builtins (logically) - though depending upon the shell implementation
which fds are stdin / stdout / stderr when the builtin runs need not
necessarily be 0 1 and 2 (if someone does "echo foo >file" (with a builtin
echo) it can be easier to open "file", and then just tell the builtin
echo to use that fd as stdout, rather than shuffling things around to
turn that into 1, after moving the old fd 1 elsewhere while echo runs,
and then back again. Doing this changes nothing about what is required.)
| For the non-standard utilities, they are not specified by POSIX, but
| their behavior may be specified by something else, and I doubt that
| the shell is allowed to mess up their normal execution just because
| they are not specified by POSIX.
I'm not sure what you think we're talking about here, but shells messing
things up is not it. What the shell must do (for any command) is specified.
What the standard utilities do is also specified - provided they're invoked
with a standard environment (which is really just the 3 open fds, argc,
argv, and environ). What other programs do is entirely up to them, isn't
standardised by POSIX, so (as far as we are concerned here) can be anything.
But of course, those programs are likely to be specified somewhere (even if
just in their own man page) and should do what they're documented to do.
The issue here is just that (for the purpose of deciding what POSIX requires)
doing tests using >&- to force write errors from (standard) utilities is
useless, as then there is no standard environment, and nothing is guaranteed
(by POSIX).
This doesn't mean that utilities (like pwd for example) which don't usually
open any files should be bothered by having one of the standard fds closed,
or not correctly opened -- unspecified doesn't mean "must do weird things",
just that no-one can complain that it is not behaving as mandated by POSIX
when that is done and something odd happens (or something expected doesn't
happen - like an error message to stderr because of a write error to stdout,
or for that matter, a non-zero exit status after that occurs).
If you want to discuss other aspects of the behaviour, beyond what POSIX
requires, you're in the wrong forum.
kre
