On Wed, 2004-08-18 at 23:34, Paul Eggert wrote: > Albert Cahalan <[EMAIL PROTECTED]> writes: > > > 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? > > Guideline 3 says "Multi-digit options should not be allowed." > That's an explicit prohibition.
I meant, where is --lines allowed, and how does this not apply to -12345 as well? Look: "Each option name should be a single alphanumeric character" So the second "-" is a violation, along with the ordering distinction between --lines and -lsn-ei. > > the long options violate guideline 3. > > I don't see why. Guideline 3 is about short options. I don't see any other kind of option allowed. > > Why would the standard warn that some systems might not be standard? > > The standard contains several warnings of that sort. It's a pragmatic > document. It hasn't been taken over by lawyers (yet :-). > > > the standard does indeed mention that the utility syntax guidelines > > might be violated by some standard-conforming implementation > > No, it doesn't say that. It doesn't say that such an implementation > conforms to the standard. Quite frankly, if non-conflicting historical behaviors are prohibited, then the standard isn't worth the paper it's printed on. How likely do you think it is that Sun and HP will drop the "head -42 ..." syntax? I'm quite sure they'd manage to get certified in spite of this. I do believe the "warning" is a loophole. In any case, the important thing is that nobody gets misled into choosing this pedantic config. You could require that POSIXLY_CORRECT or POSIX_ME_HARDER be set before disabling the historical options. You could require that somebody passes "--pointlessly-pedantic" to the configure script. Whatever, as long as nobody trips on this. Stuff is needlessly breaking. Perhaps a correction to the standard is in order, if indeed you are correct about the lack of an allowance for supporting historical behavior that does not conflict with standard behavior. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
