Re: "conformance" vs. compatibility

[Jim Meyering]

address@hidden (Paul Jarc) wrote:
> Jim Meyering <address@hidden> wrote:
>> After 10 years of being merely `obsolescent', head -N has finally
>> been officially declared to be `obsolete'.
>
> This doesn't respond to Ari's argument, though: given that GNU
> utilities already go beyond the standard's requirements by supporting
> long options, why not also preserve -n/+n arguments as extensions,

Going beyond the requirements (in an explicitly-permitted fashion)
is not the same as violating the standard.  Making head accept
+n/-n would violate the standard.

With a conforming implementation of head, `head +1'
must try to print the first 10 lines of the file named `+1'.

Besides, that old option syntax is incompatible with the guidelines
that attempt to make it so most tools treat command-line options
consistently.

The option syntax guidelines were drafted for a good reason.  For example,
before this change, using `head *' would fail not only for a file whose
name starts with `-', but also for one that starts with `+'.  Having to
worry about a leading `-' is bad enough.  Having to learn/remember that
for a handful of programs, a leading `+' is also special is not ideal.

And of course, it *is* still possible to obtain the old behavior
by setting e.g., _POSIX2_VERSION=199209 in the environment.

> especially since so much existing code relies on them?  AFAICT, the
> only defense of long options is that even though they don't follow the
> standard, they are useful.  Isn't the same true of -n/+n?