[Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.

[Denys Vlasenko]

On Tuesday 16 September 2014 20:53, Joshua Judson Rosen wrote:
> On 2014-09-05 12:26, Ralf Friedl wrote:
> > Xabier Oneca -- xOneca wrote:
> >> Hello again,
> >>
> >> 2014-09-05 18:19 GMT+02:00 Xabier Oneca  --  xOneca <xoneca at gmail.com>:
> >>> Hello list,
> >>>
> >>> I want to highlight what GNU coreutils' help docs (info coreutils
> >>> 'false invocation') says about false when invoked with --help:
> >>>
> >>>> Note that `false' (unlike all other programs documented herein)
> >>> exits unsuccessfully, even when invoked with `--help' or `--version'.
> >>>
> >>> I think Busybox should do the same with the applet.
> >> And I want to add that --help will only be used ever in an interactive
> >> shell by a person, so the return value may be dispensable. (i.e.
> >> doesn't mind to the user how does --help return as soon as the help
> >> text is printed in screen)
> > Actually this is the argument to leave it as it is, because nobody cares about
> > the return value of "false --help".
> 
> I care about the value of "false --help". Well, actually, let me rephrase:
> I care that I can force a failure by swapping in "false" in somewhere where
> a user-supplied command is called, without having to do extra work to
> to sanitise the arguments sent to the callback. Being able to force failures
> is an important part of being able to debug problems.
> 
> I've seen plenty of situations where "--help" can make its way into a command
> that wasn't just written by a user in a shell; either intentionally or
> unintentionally. Maybe I don't care about what happens when I explicitly,
> literally type "false --help" into a shell, and maybe I'm never going
> to write "if false --help; then ...; fi" in a script; but even if I don't
> care about those, I certainly care what happens when I call "$CMD "$@""
> and $CMD just happens to be "false" or "$@" just happens to include "--help".
> I assign "false" to variables like "$CMD" quite frequently.
> Isn't that exactly the sort of thing that "false" is for?
> 
> There's also the issue of "busybox false --help" and "busybox sh -c 'false --help'"
> being incompatible with each other. That's awfully confusing--demonstrated by
> the exchange between Harald, Bastian, and myself demonstrates. Maybe it's possible
> to argue that "busybox sh -c 'false --help'" should be changed to also return
> EXIT_SUCCESS; but it seems much more natural to me to argue in the other 
> direction ;)


Fixed in git. Thanks.