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

[dietmar.schindler at manroland-web.com]

> Von: Laurent Bercot
> Gesendet: Montag, 1. September 2014 10:49
>
> On 01/09/2014 09:20, dietmar.schindler at manroland-web.com wrote:
> > That does not follow. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04
> >  talks in the OPTIONS section about "arbitrary options that the implementation may provide as an extension"
> >  (as --help is) and that "utility options [...] modify the actions of the utility".
> >  (Also, it says: «When this section is listed as "None.", it means that the implementation need not support
> >  any options.» That doesn't mean "may not".)
> > The EXIT STATUS section also talks about "implementations with extensions", thus it seems evident to me
> >  that extensions may modify the exit status as part of their actions.
>
>   I disagree with your interpretation. Modifying the actions of the utility does not mean modifying its
> exit code. I see nothing in EXIT STATUS that says that extensions are allowed to modify the exit status
> - on the contrary, POSIX insists on "maximum portability".

The DESCRIPTION section of the abovementioned document says: "See the utility's EXIT STATUS and CONSEQUENCES OF ERRORS sections for all actions associated with errors encountered by the utility." In the presence of this, how can you conclude that the return of an exit status were not part of a utility's actions?
When we read the phrase "maximum portability" in its context ["A conforming application should be written so that it tests for successful exit status values (zero in this case), rather than relying upon the single specific error value listed in this volume of POSIX.1-2008. In that way, it has maximum portability, even on implementations with extensions.] we see that this actually addresses the very case of an extension returning another value than the one specified, don't you think?

>   Think about false. An implementation that returns 1 no matter what arguments it is given is
> conforming, so false --help is expected to return 1 by implementations that do not understand
> the --help option.

I can consent to this.

>  An implementation that understands --help and returns 0 exhibits a
> different behaviour from a conforming implementation, ...

Let's not overlook that it's a different behaviour from just *a* conforming implementation (the one you mentioned) - still there are other conforming implementations.

> ... and directly contradicts the EXIT STATUS section of the "false" page:
>
>     The false utility shall always exit with a value other than zero.
>
>   Note the "always", which is not necessary, but serves to drive the point home.

Funny that you say so... the "always" almost made me change my mind.

>   I maintain that false is NEVER allowed to return 0, --help or not.

Still my understanding is that the specified behaviour only applies to the specified options (in this case "None") and that extension options may modify the behaviour.
--
Regards,
Dietmar Schindler
________________________________
manroland web systems GmbH -- Managing Director: Joern Gossé
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail.

! Please consider your environmental responsibility before printing this eMail !
________________________________