bug#15157: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't

[Linda Walsh]

Paul Eggert wrote:
> The -g and -h options of 'sort' are indeed incompatible; they
> result in different outputs.
>
> More generally, these bug reports reargue the 'grep' bug reported here:
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html
---
        Not really.  There was nothing about the similarity and
overlap of sort options and how integer is still in the class
of general numbers, which includes 'e' as an abbreviation for
a power prefix, just like KMG are power prefixes as well.

        You can't claim that 3.2e+3, where e indicates some
power of 10 follows, and is used  as a scaling factor for 3.2 is
that different from 3.2k, where k is a scaling factor, and, indicates
that 3.2 is scaled by a factor of 10**3.

        They are both general numeric cases... I don't think
I had anything to say, at all, about the overlap of such in grep,
which is inconsistent with itself:

  grep -d read -d skip --color=auto --color=always  foo
(no error)...

  GREP_OPTIONS="-d skip --color=auto -P"
  grep -E "this|that"
  grep: conflicting matchers specified
???
I didn't specify them on the command line -- OR now:
   egrep "this|that"
   egrep: egrep can only use the egrep pattern syntax
But I didn't specify any other syntax... oh.. it reads the cmdline
options of 'grep', but it can't function like grep?  That sounds
a bit ill-designed.

-------
Please don't try to take over and confused bugs on other utils, just
to put forth your view that utilities should default to broken unless
the user invokes them perfectly.

That's a bad User Interface design -- computers are supposed to
be there to help us -- not to enable those who enjoy making others
wrong to do so on a wide scale.


> and replied to here:
>
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html
>
> Generally speaking, the GNU utilities follow the POSIX utility
> syntax guidelines, in particular Guideline 11:
>
>     The order of different options relative to one another
>     should not matter, unless the options are documented as
>     mutually-exclusive and such an option is documented to
>     override any incompatible options preceding it.
>
>     
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
>
> It sounds like you're disputing the main part of this guideline
> and are advocating always taking the second (exceptional) part.
---
The 2nd part has been the norm.  While you are claiming that the
exceptional design should be the norm.

Let me know how specifying your options out of order on gnu tar works
out... There are many contexts where one option enables or disables
others.  The idea that options should be order independent is as
absurd as the idea that the lines in a "C" program should also be order
independent.  This is a perfect example of the ivory tower thinking that
is dominating POSIX now.  While they used to be more practical and describe
what was, now they've jump to the forefront to dictate bad design and
dumbed-down interfaces.   Have you ever thought about the fact that they are
funded by Corporations who might have an interest in seeing Linux's
open nature be killed off -- and/or it's usage reduced?


> It's not clear to me that this makes sense, and there are
> good arguments for sticking with the more-cautious approach.
----
So you have said, but name some that would be true for most people and
make more sense than the previous, deterministic approach...

As it is, I could point to sources by "them" and talk about what
"they" said and "everyone knows"... to make my point, but I'll
rely on the common sense that most people have in knowing that
having programs that are resilient in the face of odd
user input and have it do something useful and predictable
is far better than having fragile programs that break on all
but perfect input.