Document file size rounding logic

[ariasuni]

I took a look at GNU coreutils docs: https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html#Block-size

Fractional block counts are rounded up to the nearest integer. ... The -h or --human-readable option is equivalent to --block-size=human-readable. The --si option is equivalent to --block-size=si.

I would recommend documenting exa's choice whether it decides to keep current logic of traditional rounding, or if it adopts ls choice of rounding up to whole block.

https://github.com/ogham/exa/issues/812#issuecomment-808772385

[missinglink]

I was also confused by this, I was expecting exa to be a mostly drop-in replacement for ls but was confused by the differing filesizes listed between two terminal tabs, one using exa while the other using ls.

As suggested, adding --binary to my alias resolves the issue, I expected this to be the default rather than an opt-in.

[missinglink]

Worth noting that my file now shows as 779M with ls and as 778Mi with exa, so it's still not exactly the same rounding logic.

The stat command for this file returns 816709632

[sisrfeng]

+1 for "As suggested, adding --binary to my alias resolves the issue, I expected this to be the default rather than an opt-in."

[eggbean]

I've added an option to display binary units to my wrapper script, so that listings can appear to be even more like ls.

https://gist.github.com/eggbean/74db77c4f6404dd1f975bd6f048b86f8