>>>> 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.
In that case, I suggest you have a really good read of the POSIX
specification, like I did before writing that message. I'm sure you
will soon spot the part that negates your claim above...
>>> 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.
Note that NOBODY has stated that additional arguments not specified by
POSIX are bugs, and also note that the POSIX standard explicitly
refutes any such claim to start with.
>>> 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.
Not quite: To be POSIX compliant, it is required to comply with the
specified behaviour IRRESPECTIVE of any non-standard arguments that
may be supplied. That's why true IS compliant, and false is NOT.
>> 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.
Horse Manure.
> And if it's just error of POSIX committee and true and false
> really should ignore arguments this must be written in
> specification. And THEN true & false must be changed...
As has been stated several times, the comments regarding number of
arguments are irrelevant, as the POSIX standard explicitly allows
them. What is in question is the exit code, in which respect false is
NOT POSIX compliant without the above patch having been applied.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/