Re: "conformance" vs. compatibility

[Paul Jarc]

Paul Eggert <address@hidden> wrote:
> address@hidden (Paul Jarc) writes:
>> If the choice is somehow truly under the control of the coreutils
>> installer, then I would be happier.
>
> It's clearly under their control now.

It's clearly under the control of the libc installer, but what if the
libc installer is not the coreutils installer?  What if I'm installing
coreutils on a system where I don't have root access, and don't want
to install my own libc?  If unistd.h doesn't define _POSIX2_VERSION,
then I can define it with "-D_POSIX2_VERSION=..." in CFLAGS.  But if
unistd.h does define it (unconditionally), then my definition will
conflict with that.

I think it ought to be possible for the user building coreutils to say
what version of conformance they want - say, with a ./configure
argument - and this should override the unistd.h definition.

>> Item 2c of the Utility Argument syntax rules allows for historical
>> cases where the option and its argument cannot be separated.
>
> No, 2c merely says that even if a utility's synopsis says "tail -n
> 35", a conforming application can still invoke "tail -n35".

But it then goes on to make exceptions, so that there may be cases
such as "tail -35" that do not behave the same way as "tail -3 5";
that's what I was talking about.  But it also says these cases are
specially marked, and tail is not marked, so scratch that.

>> Long options are not single characters.
>
> Correct.  They do not follow the utility argument syntax at all.  No
> option can possibly use the character '-', because '--' is already
> reserved by the standard.  This is an escape hatch that long options
> can use, but '-10' and '+10" cannot use.  And I think this is why the
> syntax for long options in GNU has changed.  It used to be '+option',
> and if memory serves it was also '-=option', but neither of these
> choices was a pure extension to POSIX; so the syntax is now
> '--option', which is a pure extension.

You are reading guideline 10 and concluding that arguments such as
"--help" cannot be options.  But we could come to that same conclusion
from guideline 2, since "-" is not alphanumeric.  "=" is also not
alphanumeric, so ISTM that "-=help" would be just as much of a pure
extension: it doesn't follow the rules, therefore it must be the kind
of thing that doesn't have to follow the rules.

If "--help" is a pure extension because it does not match the syntax
rules, and if "+help" also does not match the syntax rules, then why
is "+help" not also a pure extension?

>> Can't this be done just as easily for -n/+n?
>
> I don't think so.  '-1' is clearly an option;

No.  "-1" clearly *can be* an option, since it matches the syntax
rules, whereas "--help" cannot be an option, since it does not.  But
where does the standard say that any argument that matches the syntax
rules for options *must be* an option, and thus must match the
semantic rules as well (e.g., that "-x -y" has the same semantic
meaning as "-xy")?

POSIX tells us "if the argument is an option, then it should obey
these rules".  But AFAICT, there is no guidance for determining
whether an argument is an "option" in the first place, other than the
standard options (e.g., head -n, but not head -c).


paul