printstat and awkprintf are very clear: print statement errors
are fatal.
In Jan 2020 [1], to prevent fatal print errors from masquerading
as fclose warnings, every WARNING in closefile and closeall became
FATAL. This broke awk's close and getline functions.
close no longer returns if there's an error, unless the stream
doesn't exist.
getline read errors still return -1, but they are no longer
ignorable. Eventually, one of the closing functions will inspect the
stream with ferror and call FATAL.
In Jul 2020 [2], fatal stdout write errors which had been detectable by
closefile for a few months became invisible, a consequence of switching
standard streams from fclose (which reports flush errors) to freopen
(which ignores them). The Jan 2020 changes which broke getline and
close were themselves partially broken.
The solution is to finish printing before closing. That is to flush
and ferror every stream opened for writing before calling fclose,
pclose, or freopen. A failure to write print statement data is
fatal. A failure to close a flushed stream is a warning. They must
be handled separately.
Every redirected print statement is finished in printstat or awkprintf.
The same is not true of unredirected print statements. To finish
these, stdout must be flushed at some point after the final such
statement. Any problem with that flush is fatal.
Though only stdout needs it, let's defensively finish every stream
opened for writing, so this bug won't recur if someone changes how
redirected streams are flushed.
Write errors on stderr by the implementation are never fatal. When
closing, we only warn of them. Write errors from an application
attempting a redirected print to /dev/stderr are as immediately fatal
as every other redirected print statement.
[1] fed1a562c3
[2] b82b649aa6
An input/output error indicates a fatal condition, even if it
occurs when closing a file. Awk should not return success on I/O
error, but treat I/O errors as it already treats write errors.
Test case:
$ (trap '' PIPE; awk 'BEGIN { print "hi"; }'; echo "E $?" >&2) | :
awk: i/o error occurred while closing /dev/stdout
source line number 1
E 2
The test case pipes a line into a dummy command that reads no
input, with SIGPIPE ignored so we rely on awk's own I/O checking.
No write error is detected, because the pipe is buffered; the
broken pipe is only detected as an I/O error on closing stdout.
Before this commit, "E 0" was printed (indicating status 0/success)
because an I/O error merely produced a warning. A shell script
was unable to detect the I/O error using the exit status.
