Re: "conformance" vs. compatibility

[Paul Eggert]

address@hidden (Paul Jarc) writes:

> How is that controlled, exactly?  I think it ought to be documented in
> README.

Good point.  The README is a bit obsolete anyway, as it talks about
"POSIX.2".  Here's a proposed patch.

2003-11-04  Paul Eggert  <address@hidden>

        * README: Document _POSIX2_VERSION.

--- README.~1.12.~      Tue Jul 29 13:55:00 2003
+++ README      Tue Nov  4 10:50:42 2003
@@ -19,8 +19,13 @@ See the file NEWS for a list of major ch
 
 See the file INSTALL for compilation and installation instructions.
 
-These programs are intended to be POSIX.2 compliant (with BSD and other
-extensions), like the rest of the GNU system.
+These programs are intended to conform to POSIX (with BSD and other
+extensions), like the rest of the GNU system.  By default they conform
+to older POSIX (1003.2-1992), and therefore support obsolete usages
+like "head -10" and "chown owner.group file".  This default is
+overridden at build-time by the value of <unistd.h>'s _POSIX2_VERSION
+macro, and this in turn can be overridden at runtime as described in
+the documentation under "Standards conformance".
 
 The ls, dir, and vdir commands are all separate executables instead of
 one program that checks argv[0] because people often rename these


> the maintainer of any given libc cannot know which utility package
> their users will choose,

The intent of <unistd.h>'s _POSIX2_VERSION is to let C programs know
what C function calls like system("head -n 1") will do.  If the libc
maintainer takes on the task of maintaining <unistd.h>, then it's the
libc maintainer's job to make sure that _POSIX2_VERSION is accurate.
Of course some cooperation is necessary between libc and coreutils
here, but in the end somebody has to decide which version of POSIX the
overall operating system is supposed to conform to, and right now
coreutils defers to the libc maintainer on this issue (perhaps partly
in the hope that unhappy users will go bug their libc maintainers to
not upgrade for a few months more, please, please, we'll promise to
fix our obsolete scripts someday but not today!... :-).


> 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.  My understanding is that some
GNU distributions have delayed conformance to the new standard by
modifying their copies of libc and/or coreutils, and that some
haven't.  It could be made a bit more convenient, I suppose, but it's
not that hard right now.


> > That's not how the guidelines work.  If 'tail' were to follow the
> > guidelines, then 'tail -35', 'tail -3 -5', 'tail -5 -3', and 'tail
> > -53' would all be equivalent.
> 
> Not necessarily.  It could instead be interpreted as, for example, the
> option 3 with argument 5.

No, because then "tail -3 5" would have to be equivalent to "tail -35".


> 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".

Perhaps you're referring to item 2b?  It says that if the POSIX
synopsis specifies that a space is not allowed between an option and
its argument, then a conforming application must omit the space.  But
as I understand it, this exception applies only to options specified
by POSIX; it doesn't apply to extensions.  For more about this, please
see the penultimate paragraph of
<http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html>,
"head" and "tail" are both required to conform to the utility syntax
guidelines, so all the "shoulds" in the guidelines are actually
"shalls", as far as "head" and "tail" are concerned.

Also, as you mentioned, even if this saved "tail -35", it wouldn't
save "tail +35".  (See below for more.)


> > A plain "--" argument cannot possibly be an option (since it is a
> > standard delimiter), and therefore "-" cannot possibly be an
> > option name.  Long options therefore are not part of the standard
> > option syntax at all; they are a pure extension.
> 
> # Guideline 3:
> #     Each option name should be a single alphanumeric character (the
> #     alnum character classification) from the portable character set.
> 
> 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.

> Can't this be done just as easily for -n/+n?

I don't think so.  '-1' is clearly an option; see, for example, 'comm
-1'.  And '+' ought to be allowed as the first character of a file
name.  I sometimes give my files names that start with '+', and I find
it annoying when 'sort', 'tail', etc. don't work on such files.  Now
that I can set _POSIX2_VERSION=200112 in my environment, I don't have
to worry about that on my host.


> > Long options are clearly useful.  It's less clearly useful to
> > support options that have been officially obsolescent for more than
> > a decade, and have been officially obsolete for almost two years.
> 
> The usefulness of -n/+n comes from existing code and habit; official
> pronouncements are irrelevant.

"Irrelevant" is a bit too strong.  There are reasonable arguments for
using a regular option syntax, even if that requires minor changes to
existing usage.  (To see why the irregularity of the historical syntax
is not always a benefit, please consult "The Unix-Haters Handbook"
edited by Garfinkel, Weise, and Strassman
<http://research.microsoft.com/~daniel/uhh-download.html>.
I particularly liked Dennis Ritchie's remarks in the book.  :-)