[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180802195136.GN1392@brightrain.aerifal.cx>
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.
