[Toybox] [PATCH] Fix ls -sh.

[enh]

On Sat, Aug 27, 2016 at 9:08 PM, Rob Landley <rob at landley.net> wrote:
> On 08/27/2016 12:25 PM, enh wrote:
>> ping. (i'd like to get this into my weekly sync, since it was reported
>> as a bug.)
>
> Sorry, I wanted to take a stab at cleaning up the redundancy, but my
> todo list hit some sort of critical mass a couple months back and has
> not let up. (Downside of a day job that does _not_ let you devote half
> of each working day to open source stuff.

ah... i often wonder where you manage to find the time! that's the
reason i tend to ping at weekends: it's easier for me to find some
time then.

> I spent bits of today reading
> about tun/tap, in hopes of clearing that and getting back to the xattr
> stuff.)
>
> Cleanup, cleanup... hmmm, is human_readable ever going to produce utf8
> output that cares about strwidth() vs strlen()? No, doesn't look like,
> which means I've got an overzealous strwidth() in there tha can go...
>
> Hmmm, it still doesn't match the host's output exactly for ls -sh
> because they're using two spaces of padding between columns and we're
> only using one. (This isn't a -h thing though, ls -s does it too, and we
> hadn't noticed/cared before...)
>
>> i did write a test, but removed it again because assumptions about
>> blocks used by the test files seemed inherently flaky.
>
> It's the "stat %B vs %o" thing all over again. According to "man 2 stat"
> the units of st_blocks are always 512 bytes, hardwired for historical
> reasons. I'll update the help text.
>
> Except...
>
>   $ ls -l stat
>   -r-xr-xr-x 1 landley landley 23000 Aug 27 21:54 stat
>   $ ls -s stat
>   24 stat
>   $ toybox ls -s stat
>   48 stat
>
> The host _isn't_ doing that, it's using 1024 byte units. (Sort of,
> dividing the stat value by 2.)
>
> Sigh, what does the man page say?
>
>        -s, --size
>               print the allocated size of each file, in blocks
>
> Nothing. No units! Is this a magic posix thing?
>
>   -s
>       Indicate the total number of file system blocks consumed by each
>       file displayed. If the -k option is also specified, the block
>       size shall be 1024 bytes; otherwise, the block size is
>       implementation-defined.
>
> Not exactly. It looks like the host is hardwiring -k on. Sigh. I can do
> that too. (Opinions? I didn't think it _used_ to do that, but I keep
> upgrading my ubuntu version and the behavior of ls subtly changes out
> from under me and what I tested against is no longer true...)

i've warned the folks who reported the original bug to me, and i'll
let you know if they have any comments. i assume they'll be happy to
match the host though. (they're the folks responsible for
reproduceable builds/unnecessary build bloat.)

> Anyway, the usefulness of the -s field is when there's holes, but it
> might as well be "actual bytes used". I'd happily change it to use units
> of bytes, but compatibility... (Although see above!)
>
> As long as we're twiddling -h, do you want it to change the date format
> to do the "Aug 27 12:34" thing (instead of "2016-08-27 12:34"?)

i _personally_ don't. i like iso and find anything else annoying
(especially because you always end up with a mix). i'll let you know
if i ever hear complaints.

fwiw, this ls -sh bug has been the first real bug in a while. (given
that i can't change the past and fix things in old releases.)

> It seems
> like -h is a logical place to do that since a script can't reasonably
> parse the result _anyway_. (I can just let strftime's %b supply the
> month name. I'd try %c but "Sat Aug 27 12:34:56 2016" isn't even close. :)
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.