>>>> 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.
> 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?
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...
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/