On 2021-06-28 22:02:22 +0000, tg...@mirbsd.org via austin-group-l at The Open Group wrote: > What’s currently left of Vincent’s issue is that the utility tries > to write to its stdout¹ which the shell has connected to something > that does not accept writes: /dev/full on systems that have it, an > existing file on a full or readonly filesystem, some pipe that was > closed, etc. > > ① Worse, stderr — in which case we can’t even show the diagnostic, > and possibly accumulate more errors.
I don't think the absence of diagnostic is much an issue in such a case (I suppose that it would just make debugging a bit more complex in such rare cases). In scripts, one generally checks the exit status, either systematically (with "set -e") or explicitly. > >My Solaris test cases corrected to use EPIPE instead of EBADF: > > > >$ (trap "" PIPE; sleep 1; /usr/xpg4/bin/sh -c 'grep root /etc/passwd; echo > >"$?" >&2') | : > >0 > >$ (trap "" PIPE; sleep 1; /bin/sh -c 'grep root /etc/passwd; echo "$?" >&2') > >| : > >0 > >$ (trap "" PIPE; sleep 1; /bin/sh -c 'pwd; echo "$?" >&2') | : > >0 > > That goes with your statement of… > > >On Solaris 11 (certified as compliant): > > … which makes me think that (besides significant vocal support on > this list) there’s significant precedent for this real-existing, > historically-founded, behaviour of not having to check for all > kinds of stdout/stderr write errors for utilities “like that” (I’d > expect text editors, for example, to still show errors of course), > the boundary of “like that” probably being that it’s not in pwd’s > domain to care about or set up its output (merely using stdout), > whereas text editors deal with filenames and open(2) etc. directly. Note that even the write errors with "grep" are not detected. If "grep" is used to filter out some lines of a file and generate some new file as a result, there would be possibly unnoticed data loss. BTW, I have a script that consists only in a "truncate" then a "grep" in a loop to generate a file, and starting with "set -e" to specifically detect write errors in these two commands. With pwd, issues are probably more unlikely, but who knows how a user will use it? > On a more technical note, changing this would be *extremely* tricky. > The shell implementation doesn’t use stdio necessarily, and sprinkling > checks all over the code will make it less maintainable, slower, and > is bound to still miss some, plus there’s the question of what to do > for each code location. In some cases, the failure to write can IMHO > totally be ignored if the tool otherwise completes its job. Finding > out which these are is also going to be tricky. I wonder what you mean here. An example would be appreciated. -- 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)
