On 2021-06-29 22:43:49 +0700, Robert Elz via austin-group-l at The Open Group
wrote:
> Date: Tue, 29 Jun 2021 09:49:40 +0100
> From: "Geoff Clare via austin-group-l at The Open Group"
> <austin-group-l@opengroup.org>
> Message-ID: <20210629084940.GA8391@localhost>
>
> | You are wrong when you say it "printed it". It tried to print it but
> | failed to do so.
>
> But how do you actually know? In the full filesystem case you might,
> but how do you really tell the difference between
>
> { sleep 1; pwd; } | :
> and
> pwd | sleep 1
>
> In neither case does the output get through the pipe. If the sleep
> wasn't there, and we just had
>
> pwd | :
>
> then sometimes we might get one behaviour, and other times the other.
>
> I assume you're not suggesting that it is the responsibility of the
> application (pwd in this case) to verify that data sent to a pipe gets
> received by some process at the other end?
>
> And if not that, then what's the point - sometimes the output is lost,
> and there's no error message, or non-zero exit status. Other times you
> apparently demand that there is. Not very consistent is it?
It may not be the same behavior, but very often, this is not an issue.
The output of the LHS command may be "lost" because:
1. The RHS command should have read more data, but terminated
abnormally / unexpectedly. In such a case, its exit status should
be nonzero (possibly with a diagnostic message), so that it is
possible to know that something got wrong.
2. The RHS command has read all the data it needed (like with "head"),
so that any lost data aren't really lost: they are just useless. In
general, the LHS command is killed by SIGPIPE, so that there is no
(useless) diagnostic message; the exit status is generally ignored
(though with some shells, the user may check it if need be). In
short, both behaviors have the same visible result. If SIGPIPE is
ignored, there may be a diagnostic message in the case one gets
an EPIPE error; only in this case, this diagnostic message may be
annoying because the EPIPE error is an expected error (though it
may be useful in other cases). Otherwise, the behavior is similar.
[...]
> pwd does write to stdout - it does (the equivalent of, in whatever
> language it is written) printf("%s\n", directory);
>
> Having done that it exits. It is finished.
The pwd command from the Coreutils does
atexit (close_stdout);
where close_stdout check any error on stdout and stderr.
Note that it has the possibility to ignored EPIPE on stdout.
BTW, it has a comment about this need:
It's important to detect such failures and exit nonzero because many
tools (most notably 'make' and other build-management systems) depend
on being able to detect failure in other tools via their exit status.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
