Date:        Sun, 4 Jul 2021 10:31:06 +0100
    From:        Stephane Chazelas <steph...@chazelas.org>
    Message-ID:  <20210704093106.2ce2cyg77f2nm...@chazelas.org>


  | That would make is non-compliant then.

s/is/it/ ... and yes, so?

  | SUS> When there are multiple key fields, later keys shall be

There was no need to quote that, I'm fully aware of how it is specified,
which I'm also not complaining about - this is a case where that actually
is (or was) the standard, as it is how sort was implemented, from long
long ago (way back before -k was invented and we just had + and -).

It's just stupid.

This is a case where systems need to simply start ignoring the standard
and doing the sane thing, so that the standard can eventually be updated
to also be sane.   That's how evolution happens.

  | I don't know what the original rationale was, but /one/
  | rationale could be to garantee a deterministic and total order,

No question but that there needs to be a method to achieve that, but
it does not need to be an undefeatable default.  It doesn't need to be
the default at all.  The default should be the most useful behaviour,
which is probably not that (its only real merit is for compat with the
ancient past).

  | to make sure that two files with the same lines (though in
  | different orders) result in the same output when sorted whatever
  | the sorting specification.

Nor is that final qualification needed.   The output order is defined
by the sorting specification, if one wants some particular order, one
must write the spec to achieve that order.  A different sorting specification
both can, and should, result in a different order.

kre

  • Re: sort -c/C and las... Robert Elz via austin-group-l at The Open Group

Reply via email to