On Wed, 2004-08-18 at 13:49, Paul Eggert wrote: > Albert Cahalan <[EMAIL PROTECTED]> writes: > > > Well, so does the --lines option. > > No, that uses an allowed extension. It's not prohibited, the way that > multi-digit options are prohibited.
Where? You can have a "-W lines=42" option. Guideline 10 seems to require that "head --help" be interpreted as "head -- help". That is, it opens a file named "help". At the very least, the long options violate guideline 3. > > I think "violates" is too strong of a word for > > anything called "Guidelines", but anyway... > > The standard says: > > The utilities in the Shell and Utilities volume of IEEE Std > 1003.1-2001 that claim conformance to these guidelines shall conform > completely to these guidelines as if these guidelines contained the > term "shall" instead of "should". > > So it's a hard requirement for (most) standard utilities. Note carefully: "conformance to these guidelines" You can claim conformance to the standard itself without also claiming conformance to the guidelines. The "head" command is described using the word "follows", instead of the words "conforms to". (for "head", the standard says "This standard version of head follows the Utility Syntax Guidelines." instead of "This standard version of head shall conform to the Utility Syntax Guidelines.") Feel like we're quoting the Bible at each other? :-) Especially in light of the statement below, it is clear that the standard is not indended to prohibit the implementation of historic BSD and UNIX syntax. > > Guideline 11 isn't even a problem at all, unless you > > artificially make it a problem. > > Sure it is. It says that order shouldn't matter unless the options > are mutually exclusive and one is documented to override the other. > Hence if options like "-1" are and "-3" are allowed, then "-13" must > be equivalent to "-1 -3" which in turn should be equivalent to "-3 -1" > or "-31". I suspect that this problem is part of the reason that > multi-digit options were disallowed. As an implementation-specific option, this is multi-digit. So there is no ordering problem. > > "On some implementations, the utilities accept > > usage in violation of these guidelines for > > backwards-compatibility as well as accepting > > the required form." > > > > Well, there you go. The POSIX and UNIX standard > > explicitly allows for the traditional behavior. > > That is a warning that some implementations don't conform to the > standard. It's certainly not a license to do whatever you want to do, > and then still claim conformance. That doesn't make sense. Why would the standard warn that some systems might not be standard? Of course this is the case. Such systems are not covered by the standard at all. Why would the standard care at all? (DOS exists...) Either a standard-conforming implementation is allowed to support non-standard extensions, or there is no reason for the standard to mention that some implementations might support such extensions. Since the standard does indeed mention that the utility syntax guidelines might be violated by some standard-conforming implementation, one must conclude that it is acceptable to violate the guidelines as long as you also implement the standard. See what I'm saying here? That paragraph has NO PURPOSE being in the standard, unless it is interpreted to mean that you can freely implement non-standard syntax in addition to the required syntax. > > Nearly everybody wants conformance. > > If nearly everybody wanted conformance, it wouldn't be > much of a problem (since almost nobody would be using > nonstandard commands like "tail -10" :-) That's the other side of things. Sure, it would be nice if scripts didn't require the old syntax. The old syntax is actually more portable though; it works on old BSD. Even today, the Solaris man page uses "head -9999" in the example. I'd be shocked to see any UNIX vendor drop the old syntax. > But at any rate it's easy to configure this, both at build-time and at > run-time. If your coreutils installation isn't configured the way you > like, just change it. When most anybody sees an option to conform to the very latest standard, they're going to pick it. So if -X meant one thing historically, and now it means something else in POSIX, the user wants POSIX. The user isn't asking to lose functionality that doesn't conflict with the standard. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
