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
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
