Jim Meyering wrote:
"James Youngman" <[EMAIL PROTECTED]> wrote:
On Tue, Sep 25, 2007 at 5:46 PM, Paul Eggert <[EMAIL PROTECTED]> wrote:
Jim Meyering <[EMAIL PROTECTED]> writes:
Mart, let me know if you can assign copyright to the FSF,
and I'll send you the paperwork.
Paul?
Paul Eggert wrote:
Jim Meyering <[EMAIL PROTECTED]> writes:
Mart, let me know if you can assign copyright to the FSF,
and I'll send you the paperwork.
Paul?
Thanks, Mart. Nobody has come up with a better solution, so let's go
with Mart's, with one proviso: it should be documented a
ions to sort:
$ du -h --max-depth=1
4.0K./bin
52M ./code
765M./Desktop
12K ./mail
17M ./music
124K./PDF
5.5G./photos
153M./public_html
652K./ufc
7.3G.
That has been asked for many times.
Perhaps we should add it?
Over a year ago, Mart Somermaa
Paul Eggert wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> As I already explained, the current implementation behaves correctly
>> with *both* SI and powers-of-1024 input, so there is no need for two
>> option letters.
>>
>
> We need
Paul Eggert wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> Why not use an upper-case letter? We have plenty of those left.
>>
>
> There are a lot of different ways to sort, and we'll burn through
> the letters fairly quickly.
Out
Paul Eggert wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> But I really don't see what's wrong with that assumption. It holds for
>> other coreutils and that's what matters most. A clearly documented
>> limitation is not a bug, but a f
Paul Eggert wrote:
> Also, I'm still leery of assuming properly scaled input.
> Is it that much harder to implement it correctly without that assumption?
>
Sorry, missed that bit in my previous mail... yes, as without that
assumption we have to use multiplication for normalization -- but then
we
Paul Eggert wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> I've never encountered such behaviour and IMHO it should be considered a
>> bug (considering both the expectations of users and the column widths in
>> 'du -h' and 'df -h&#
Paul Eggert wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> - the implementation is simple, effective and 2^n/10^n-problem agnostic
>> (at the cost of comparing 10K less than 1M, which is not a problem
>> as we assume the input to be properly sca
Paul Eggert wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> What is the general consensus on adding the '--human-readable-bytesize'
>> otpion to sort?
>>
>
> A problem with it is figuring out how to add lots of options to sort.
&
What is the general consensus on adding the '--human-readable-bytesize'
otpion to sort? The initial response seemed positive and I personally
crave for the feature for 'du -hs | sort -h'.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://list
Andreas Schwab wrote:
> Mart Somermaa <[EMAIL PROTECTED]> writes:
>
>
>> @@ -295,6 +299,7 @@ Ordering options:\n\
>> "), stdout);
>>fputs (_("\
>>-b, --ignore-leading-blanks ignore leading blanks\n\
>> + -B, --size-in-b
Andrew D Jewell wrote:
>> I like the idea, but I object to using up yet another single-letter
>> option for this (they're not renewable - the ASCII character set has a
>> fixed size). I suggest that we use a long option only.
>
> I agree halfway. As a separate command line argument, using up anoth
I've attached a patch that adds support for human-readable bytesize
comparison to 'sort', i.e. numbers suffixed with K for kilo-, M for
mega- and G for gigabytes are sorted correctly, if option '-B' is
given in command-line arguments:
---
$ sort --help | grep bytesize
-B, --size-in-bytes
14 matches
Mail list logo
