"conformance" vs. compatibility

[ari]

I notice that the 'head' and 'tail' commands, in the latest version of
coreutils, were modified to do away with the following options:

        -<number>  (head, tail)
        +<number>  (tail)

This breaks compatibility with a number of unix scripts.  This
compatibility disruption cannot be introduced lightly, and programs that
do not follow it cannot be considered buggy --- the most you can claim
of them is that they are not "posix compliant".  I'll delve further into
this shortly.

Under the coreutils.info heading of "Standards conformance", the first
paragraph notes that some utilities must break posix conformance, and
that the environment variable '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.

I must also address the interpretation of "posix compliance" as it
pertains to these utilities.  For this, i bring the following points:

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

  - 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 is, unless one would like to
    create a system that requires strict posix compliance of all
    executables present.  This may seem like a desirable scenario to
    some, but it's unlikely to occur.

    It's possible that in the 2001 edition, the requirements were more
    strict.
    
  - Simply because the option is not listed in the sample 'head' manual
    page does not mean that the option should not be supported.  GNU
    utilities support many options that are not covered in posix.

  - The syntactic guidelines of "IEEE Std. 1003.1" (2003 Edition),
    despite their liberal usage of the word "should" in lieu of "shall"
    or "must", display perhaps the most compelling reason to strip the
    utilities of these features.  Guideline 3 states that options should
    be a single alphanumeric character.  Guideline 5 states that
    grouping options should be allowed.  And guideline 11 states that
    the order of options should not matter.

    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.  This
    argument has holes in it, but none more obvious than the fact that
    it doesn't cover 'tail +35', as '+' isn't considered an argument.

    One may also argue that these aren't options at all, but are rather
    initial operands.  The problem with this argument is that they're
    not covered in the posix manual page synopsis.  I believe the best
    argument to keep these options remains that they are required for
    compatibility.

    To illustrate my position further, let's examine another way that
    these programs "violate" posix standards: long options.  Guideline 3
    states that options should be a single alphanumeric character.
    Guideline 5, again, states that the grouping of non-argument options
    should be allowed.  Even if we consider a long option to be a short
    option of '-', with an argument of the option name (with value, if
    applicable), we run into the problems that (1) '-' is not
    alphanumeric, and (2) the option value would need to be specified in
    the same argument as the short option ("violates" guideline 6).
    Additionally, guideline 10 states that '--' is reserved for ending
    the list of options, and that it should be used for neither an
    option nor an operand.

    To confuse matters further, if the 'POSIXLY_CORRECT' environment
    variable is set, this behavior does not change --- long options are
    still interpreted as 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.

  - The syntactic guidelines of "IEEE Std. 1003.1" (2003 Edition) also
    state the following:

        On some implementations, the utilities accept usage in violation
        of these guidelines for backwards-compatibility as well as
        accepting the required form.

    This recognizes that it is not feasible in many cases to discard
    backwards compatibility.

While these features may be considered obsolescent by some, they are
certainly not obsolete.  They are in wide use today, and on many
implementations, their successors do not exist.  I hereby request that
their revocation be reconsidered and recalled.

ari