[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: sort -h?
From:       Rob Landley <rob () landley ! net>
Date:       2022-01-10 14:05:01
Message-ID: 30b4e298-4073-f24f-4b41-25cd796a5f49 () landley ! net
[Download RAW message or body]

On 1/6/22 3:37 AM, Denys Vlasenko wrote:
> Good day Rob.
> 
> On Thu, Jan 6, 2022 at 12:59 AM Rob Landley <rob@landley.net> wrote:
>> We presumably got pinged by the same guy. Over on my side of the mirror
>> https://github.com/landley/toybox/issues/184 and
>> https://github.com/landley/toybox/issues/312 resulted me adding and then
>> removing the feature again:
>>
>> commit b0a4a96e36da616dabff85917c0155b1dd59f45c
>> Author: Rob Landley <rob@landley.net>
>> Date:   Sun Jan 2 20:05:09 2022 -0600
>>
>>     Remove non-posix "sort -h".
>>
>>     The man page says this is EXPECTED to be in the wrong order:
>>
>>       $ echo -e '12345K\n1M' | sort -h
>>       12345K
>>       1M
>>
>>     That's not how toybox treats numerical units anywhere else, and our options
>>     are to be incompatible with the broken gnu thing, inconsistent with
>>     the rest of toybox, or not have the broken non-posix feature. So yank it.
> 
> I assume they want to be able to sort outputs like "df -h".
> In those cases, they assume the values are not "malformed"
> in the sense of using numbers like e.g. 3456K _and_ 2M
> in the same output. They assume the input has a fixed cutoff
> value where the output switches from "K" to "M".

If "malformed input" is not considered a valid test, then me actually getting
the result _right_ when coreutils gets it wrong shouldn't be a notable
incompatiblity, so I guess I could put it back. But:

  $ echo -e '999999K\n1M' | sort -h
  999999K
  1M
  $ echo -e '999999k\n1m' | sort -h
  1m
  999999k

The reason coreutils gets the second one right is it doesn't recognize lower
case k and m. I am NOT implementing an exact match to that behavior. (Mine was
case insensitive for the suffixes, so MULTIPLE types of incompatible already...)

> I think the idea is that with this logic, they don't need to assume
> whether "K" is 1000, 1024 or anything else.

  $ toybox --help | tail -n 6
  Numerical arguments accept a single letter suffix for
  kilo, mega, giga, tera, peta, and exabytes, plus an additional
  "d" to indicate decimal 1000's instead of 1024.

  Durations can be decimal fractions and accept minute ("m"), hour ("h"),
  or day ("d") suffixes (so 0.1m = 6s).

Toybox has defined behavior and tries to be internally consistent: if it's
decimal it has a d. I'm aware of compatablity with historical implementations
that don't, that posix has holes you can drive a truck through, and that the
Linux Foundation strangled the Linux Standard Base to the point
wikipedia[citation needed] refers to the project entirely in the past tense. But
toybox being incompatible with TOYBOX makes my teeth hurt.

>> 2 days later, busybox added sort -h, but I can't find any comment on the list
>> about it?
> 
> There was a BZ:  https://bugs.busybox.net/show_bug.cgi?id=14491
> "Support sort -h" from someone called Kasper.

Yup, same guy:

  https://github.com/landley/toybox/issues/312

Picked it up from this guy:

  https://github.com/landley/toybox/issues/184

> I looked into how this can be made to work and it turned out to be rather easy.

It was easy for me too, it just wasn't RIGHT. :)

I'm not questioning your decision: you're compatible with coreutils in the edge
case, and that's the side busybox has erred on forever. That's right for YOU. I
just need to figure out what to do in MY project. I was hoping that you hadn't
noticed and implemented the non-crazy behavior so I could then use that as an
excuse to put back MY non-crazy behavior, but no...

So I need to figure out if it's better (for toybox) to:

A) have the feature compatible with the rest of toybox
B) have the feature incompatible with the rest of toybox
C) not have the feature

/me wanders off back to my side of things...

Thanks for the time,

Rob

P.S. heads up https://lists.gnu.org/archive/html/coreutils/2022-01/msg00008.html
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]