lkml.org 
[lkml]   [1999]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.059 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site