> Hi there.
>
> >>>> It's BROKEN -- it breaks the semantics of true(1) and false(1),
> >>>> which among other things is that they ignore any arguments.
> >>>> Hence it is a BUG.
>
> >>> It can be called BUG ONLY if you can show some POSIX
> >>> specification where said that true(1) and false(1) must ignore
> >>> any arguments. Till not shown otherwise it's FEATURE. You can
> >>> like or dislike this FEATURE but you can not clain that it's BUG
>
> >> Hmm - probably I shouldnt answer, but now that I have POSIX.2 here
> >> next to me:
>
> >> 4.23 false:
> >> Options: None.
> >> Operands: None.
> >> Exit Status: The false utility always shall exit with a value
> >> other than zero.
>
> >> Since GNU false sometimes does `exit 0' it certainly is not POSIX
> >> compliant.
>
> > GNU false ALWAYS "exit with value other then zero" when called
> > without options and operands.
>
> In otherwords, you admit that it's buggy as you have to add a
> condition to get it to agree with the POSIX specification.
>
No. I'm not add ANY ADDITIONAL CONDITIONS. Just explain what means:
options: None & Operands: None. IF true is used without options and
operands you must get "exit with value other then zero". If you try to
specify options and/or operands you are out of standard definition.
> > I can not see how text above imply that false should IGNORE
> > arguments.
>
> Neither do I, but that's not what's in question here...
>
> > If such thing as additional arguments not specified by POSIX are
> > bugs then [almost] all GNU utilities are buggy: most of them
> > will allow additional arguments.
>
> > When GNU true and false used according to POSIX (i.e. without
> > arguments) then work like POSIX specify.
>
> What's wrong with false complying with the POSIX specs even when it is
> supplied with arguments, like true already does?
>
No. In "Single Unix Specification v2" written that true and false should
not use stdout. But yet again: there are also written that true and false
does not permit operands ! And thus when you try to call true or false
with options or operands you are out of standard scope. ANYTHING can
happen.
> Here's a patch file to bring it into compliance:
>
> ===8<=== CUT ===>8===
> --- /bin/false~ Tue Jul 7 05:42:29 1998
> +++ /bin/false Tue Apr 6 00:50:01 1999
> @@ -14,5 +14,5 @@
> z--help )
> - echo "$usage"; exit 0 ;;
> + echo "$usage"; exit 1 ;;
> z--version )
> - echo "false (GNU sh-utils) 1.16"; exit 0 ;;
> + echo "false (GNU sh-utils) 1.16"; exit 1 ;;
> * ) ;;
> ===8<=== CUT ===>8===
>
> Perhaps somebody should forward that patch to 'Professor' Stillman...
>
It's not needed. It's ALREADY standard-compliant. And if it's just error
of POSIX cometee and true and false really should ignore arguments this
must be written in specification. And THEN true & false must be changed...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/