Lucas Nussbaum <[EMAIL PROTECTED]> writes:
>> Come to think of it, if -h implied -g instead, you might have a
>> simpler implementation (albeit one with rounding errors and slower
>> performance).
>
> This would break with exabytes.
Why? -g uses floating point, and 1 EB (10**18) can be represent
On Sun, Sep 05, 2004 at 04:49:38PM -0700, Paul Eggert <[EMAIL PROTECTED]> wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
>
> > So 12345K < 1M, but I think it is acceptable if
> > properly documented (no software will never output 12345K).
>
> Unfortunately some software does output "12345K".
Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> So 12345K < 1M, but I think it is acceptable if
> properly documented (no software will never output 12345K).
Unfortunately some software does output "12345K". For example:
$ echo '' | dd bs=1 seek=12641279 of=big
1+0 records in
1+0 records out
$ ls
Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> Is there a reason why this is not implemented ?
Lack of time, basically.
> If not, I'll try to submit a patch adding a -h option, available
> only with -n.
Thanks. Here are some thoughts.
Beware the decimal-point character: it's locale-dependent.
Hi,
There's something I miss terribly in sort : it's the possibility to do
something like :
du -hs * | sort -n
It won't work, because sort doesn't understand human readable format
(1K, 234M, 2G).
Is there a reason why this is not implemented ? If not, I'll try to
submit a patch adding a -h option
