Re: "conformance" vs. compatibility

[Paul Jarc]

Jim Meyering <address@hidden> wrote:
> 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.

Where is the explicit permission for long options?

Here is the explicit permission for +n/-n:
# On some implementations, the utilities accept usage in violation of
# these guidelines for backwards-compatibility as well as accepting
# the required form.

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

s/+1/--help/g
Still true?

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

The guidelines are themselves incompatible with existing code.
Anyway, since you say "most", not "all", why not let head and tail be
among the few that do not follow the guidelines?

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

I would say: given that we already have to worry about "-", having to
also worry about "+" is not significantly worse.  Worrying about "-"
puts us in the habit of using "./*", which protects us from "+" too.

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

Having an extra hoop to jump through seems gratuitous.


paul