Messages in this thread | | | Date | Tue, 6 Apr 1999 04:22:39 +0400 (EEST) | From | Khimenko Victor <> | Subject | Re: GNU/Linux stance by Richard Stallman |
| |
On Tue, 6 Apr 1999, Riley Williams wrote:
> 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/
| |