Date: Thu, 2 Aug 2018 15:51:36 -0400 From: Rich Felker <dalias@...c.org> To: Jonny Prouty <jonathanprouty@...il.com> Cc: musl@...ts.openwall.com Subject: Re: Unexpected behaviour writing to /dev/full On Thu, Aug 02, 2018 at 02:53:26PM -0400, Jonny Prouty wrote: > Or it could be that it is just extremely commonplace to NOT check whether > you were able to successfully write to stdout before exiting. In which case > you are absolutely correct, this would be a bug in busybox (and similar > bugs in many other programs). I just tested both of the following commands > on systems using musl, uclibc-ng, and glibc, all returned 0: > > # bm's vim > # vim --help &> /dev/full; echo $? > 0 > > # gnu tar > # tar --help &> /dev/full; echo $? > 0 > > I'm leaning towards this is just the app didn't check whether their write > to stdout was successful. Thanks for your help Rich. > > > P.S. Please excuse my brevity, I am corresponding from my phone. > > On Thu, Aug 2, 2018, 2:32 PM Jonny Prouty <jonathanprouty@...il.com> wrote: > > > I am indeed using busybox ls, but I can get similar behavior when running > > things that aren't shell builtins. For instance in Alpine if you run: > > > > # /bin/rc-status > /dev/full ; echo $? > > 0 > > > > or > > > > #/sbin/update-conf --help &> /dev/full ; echo $? > > 0 > > > > Some programs do behave as I'd expect, however > > > > # /sbin/apk --help> /dev/full ; echo $? > > 1 > > > > Something seems amiss. What exit status the application wants to use is up to the application, but as a matter of quality of design, it only makes sense to return a failure exit code if the primary function the command was supposed to perform did not work. Programs where the primary function is their output, and the output is intended to be consumable/parsable by other programs, should definitely exit with nonzero status if they fail to write the full output, since bad things could happen if a script acts on their incomplete output thinking it was complete and correct. But there's really no good argument that failure to print a usage message needs to be considered an error, and treating failure to print unimportant status output as an error when the primary function of the command already succeeded is probably a really bad idea. In any case, libc has no control over the exit status; it's the application's choice what to return. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.