Re: POSIX misunderstanding

[Albert Cahalan]

On Wed, 2004-08-18 at 13:49, Paul Eggert wrote:
> Albert Cahalan <address@hidden> 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.