From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13102 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Unexpected behaviour writing to /dev/full Date: Thu, 2 Aug 2018 15:51:36 -0400 Message-ID: <20180802195136.GN1392@brightrain.aerifal.cx> References: <20180802180306.GL1392@brightrain.aerifal.cx> <20180802180509.GM1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1533239391 300 195.159.176.226 (2 Aug 2018 19:49:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2018 19:49:51 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Jonny Prouty Original-X-From: musl-return-13118-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 02 21:49:47 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1flJbS-0008M0-OS for gllmg-musl@m.gmane.org; Thu, 02 Aug 2018 21:49:42 +0200 Original-Received: (qmail 13329 invoked by uid 550); 2 Aug 2018 19:51:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12287 invoked from network); 2 Aug 2018 19:51:50 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13102 Archived-At: 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 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