Re: rc of built-in printf

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Mar 16, 2022 at 07:00:12AM +0700, Robert Elz wrote:
 > This issue was brought up on the austin-group list (POSIX) by
 > some doing testing in linux, with output from commands being sent
 > to /dev/full (yes, a special file whose only purpose, as far as
 > I can tell, is to return ENOSPC to any write request).

Yes, that's what /dev/full is for. It's surprisingly useful for
testing, especially in a world where full disks rarely happen but
silent data corruption when it does happen isn't really acceptable.

Though with one thing and another a very small tmpfs is probably more
useful today.

 > Anyway, in the next version, POSIX is planning on making it mandatory
 > for lots of commands to check for write errors on stdout, and if found
 > exit with a status indicating an error (which also mandates a message
 > on stderr from almost all utilities).
 > 
 > I don't much like this, but my arguments fell on deaf ears, so despite
 > my misgivings, in current, both versions of both echo and printf (the
 > builtin ones in /bin/sh and the ones in the filesystem) do check for
 > errors and report them (and exit non-zero) if they happen.
 > 
 > None of the many other utilities (built into sh, and otherwise) has been
 > changed, except I think maybe the built-in pwd in sh (not sure if I did
 > that one or not now) - pwd received a lot of attention because pwd was
 > the command which (pwd >/dev/full) which started all of this.

Reporting ENOSPC (or EDQUOT) and such seems like a considerably
different mission from reporting EPIPE, which is noise... but it also
wouldn't surprise me to hear that they missed this point. :-|

-- 
David A. Holland
dholland%netbsd.org@localhost