Re: "conformance" vs. compatibility

[Paul Eggert]

ari <address@hidden> writes:

> 'POSIXLY_CORRECT' may be specified if strict posix compliance must
> be followed.  I see no reason why this cannot be the case with the
> 'head' and 'tail' functions.

My feeling is that POSIXLY_CORRECT is not something that users would
normally want to set, whereas the choice of POSIX standards is
something that users have to deal with on occasion (unfortunately).
That is why coreutils has the _POSIX2_VERSION environment variable.
Setting _POSIX2_VERSION=199209 in your environment causes 'head',
'tail', etc. to behave the way that you'd like.

It's up to your the coreutils installer (typically a software
distribution maintainer) to specify the default value for
_POSIX2_VERSION.  If they don't specify a default value, coreutils
defaults to the older standard.  So the compatibility problems that
you mention occur only when the coreutils installer has indicated a
desire to conform to the new standard by default (even when that is
incompatible with the old standard).  If you like, you can always ask
your coreutils installer to build coreutils so that it defaults to the
old standard instead of to the new one.


>   - Posix was designed to increase portability.  Strict "conformance" in
>     this manner cripples portability instead.

It hurts some kinds of portability and helps others.  It depends on
what you want.  Admittedly it is a judgment call.


>   - In "IEEE Std 1003.1" (2003 Edition), the 'head' manual page states
>     (under the "APPLICATION USAGE" header):
> 
>         The obsolescent - number form is withdrawn in this version.
>         Applications should use the -n number option.
> 
>     Note the use of "should" here.  If applications using 'head' are not
>     _required_ to use the '-n number' option, then the actual program
>     should definitely support it.

That doesn't follow.  For example, an application can stop using "head
-3" and can instead use "sed 3q".  The application is not required to
use "head -n 3".


>     That is, unless one would like to create a system that requires
>     strict posix compliance of all executables present.

I think we all agree that coreutils shouldn't require that all its
users strictly conform to POSIX.  However, coreutils does have a goal
of conforming to POSIX itself.


>   - GNU utilities support many options that are not covered in posix.

True, but these options aren't under dispute, as they follow the
syntactic guidelines of POSIX.  There is a consistency argument for
sticking to the guidelines.


>     One may argue that 'tail -35' does not result in a multi-digit
>     option of 35, but rather a null option, with argument of 35.

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.  I don't think anybody'd like that.


>     To illustrate my position further, let's examine another way that
>     these programs "violate" posix standards: long options.

I don't see why they "violate" the standards.  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.  I suspect this is by design, as RMS was involved in
the original POSIX specification effort, and RMS likes long options.


>     I fail to see why the GNU utilities should be configured to
>     break posix "compliance" for the convenience of long options,
>     yet not for the requirement of portability.

It's a judgment call.  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.


> While these features may be considered obsolescent by some, they are
> certainly not obsolete.

One can argue about de facto, but clearly they are obsolete de jure.
At some point developers should get used to writing portable code that
does not use the features.  Reasonable people can disagree on when
that point should be.

In the "All progress depends on the unreasonable man" department, I've
been running with _POSIX2_VERSION=200112 in my environment for many
months.  Any programs that want to be portable to my environment have
to be fixed to not rely on these obsolete features.  It's not been
much of a problem, really.  (I use Debian, if that matters.)