Messages in this thread | | | Date | Tue, 6 Apr 1999 18:55:19 +0100 (GMT) | From | Riley Williams <> | Subject | Re: GNU/Linux stance by Richard Stallman |
| |
Hi there.
RW>>>> As has been stated several times, the comments regarding RW>>>> number of arguments are irrelevant, as the POSIX standard RW>>>> explicitly allows them.
KV>>> Where ?
GD>> POSIX.2, 2.11.3: GD>> Options: When this subclause is listed as `None' it means that GD>> the implementation need not support any options.
GD>> POSIX.2, 2.11.4: GD>> Operands: When this subclause is listed as `None' it means that GD>> the implementation need not support any operands.
KV> May be it's just my poor english but "need not" and "CAN NOT" KV> are different things ...
So we agree at last - the standard says "need not" where you were insisting on "can not"...
For reference, courtesy the "Dictionary of British and American English", I note that the meanings for those two phrases doesn't change between the two dialects...
1. "Can not" states that there is no possibility of the stated event ever happenning.
2. "Need not" states that whilst it is not required for the stated event to happen, it is also not required that it does not happen.
In the context under discussion, the POSIX standard uses the second phrase to describe the arguments taken by `false` and `true`, thus giving the following requirements:
1. `true` is expected to ignore any arguments or switches passed to it, but may act on them if it sees fit. However, irrespective of any actions taken relating to any arguments, it will always exit with the status code indicating success.
Since it does just this, `true` can be declared POSIX compliant.
2. `false` is expected to ignore any arguments or switches passed to it, but may act on them if it sees fit. However, irrespective of any actions taken relating to any arguments, it will always exit with the status code indicating failure.
Whilst it does this in most cases, there are two cases where it fails to do so, namely when either --help or --version is given as the ONLY argument to the command, in which case it exits with the status code indicating success, contrary to the POSIX specs. `false` is therefore not POSIX compliant due to this BUG.
I therefore repeat my claim that the patch I posted earlier, which you so cavalierly dismissed as unnecessary, IS in fact necessary to bring `false` into compliance with the POSIX standard.
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/
| |