* Andy Shevchenko <andy.shevchenko@xxxxxxxxx> [230501 15:57]: > On Mon, May 1, 2023 at 10:36 PM Kent Overstreet > <kent.overstreet@xxxxxxxxx> wrote: > > > > On Mon, May 01, 2023 at 11:13:15AM -0700, Davidlohr Bueso wrote: > > > On Mon, 01 May 2023, Suren Baghdasaryan wrote: > > > > > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > > > > > > > > Previously, string_get_size() outputted a space between the number and > > > > the units, i.e. > > > > 9.88 MiB > > > > > > > > This changes it to > > > > 9.88MiB > > > > > > > > which allows it to be parsed correctly by the 'sort -h' command. > > But why do we need that? What's the use case? > > > > Wouldn't this break users that already parse it the current way? > > > > It's not impossible - but it's not used in very many places and we > > wouldn't be printing in human-readable units if it was meant to be > > parsed - it's mainly used for debug output currently. > > > > If someone raises a specific objection we'll do something different, > > otherwise I think standardizing on what userspace tooling already parses > > is a good idea. > > Yes, I NAK this on the basis of > https://english.stackexchange.com/a/2911/153144 This fixes the output to be better aligned with: the output of ls -sh the input expected by find -size Are there counter-examples of commands that follow the SI Brochure? Thanks, Liam
