On 2023-12-21 19:26, Paul Eggert wrote: > On 2023-12-21 13:19, Zack Weinberg wrote: >> Sorry, I'm with GNU here: failure to report errors on writing to >> stdout is a bug. No excuses will be accepted. > > Agreed. printf commands that silently succeed when they can't do the > requested action are simply broken.
I tested several modern, current operating systems, including: OpenBSD 7, NetBSD 9, FreeBSD 13, Alpine Linux 3.15 I also tested several not-so-modern systems, including: DJGPP, HP-UX 11, Solaris 8. On every single one of these systems, the /usr/bin/printf (or equivalent) does not generally diagnose errors that occur when writing to standard output, and an exit status of 0 is returned. Further notes: The shell on FreeBSD has a printf builtin which does diagnose such errors and does exit with a nonzero status. The shell on Alpine has a printf builtin which does not diagnose such errors but does exit with a nonzero status. The shell on NetBSD has a printf builtin which does not diagnose such errors and exits with a 0 status. The DJGPP bash shell has a printf builtin which does not diagnose such errors and exits with a 0 status. The version of bash that comes with Solaris 8 has a printf builtin which does not diagnose such errors and exits with a 0 status. The other systems tested do not have printf builtins in their shells, so plain "printf" invokes "simply broken" /usr/bin/printf. So sure, we can call it a "bug" and we can call these systems "simply broken" but the reality is that these systems exist and portability means dealing with this behaviour even if it is not what we wish they would do or what some piece of paper says they should do. There are probably a lot more systems with a "simply broken" printf, as the printf utilities in SVr4 and 4.4BSD will also behave like this... Cheers, Nick
