On Sun, Jan 20, 2013 at 10:55 AM, Pádraig Brady <address@hidden> wrote:
On 01/19/2013 10:47 PM, Bernhard Voelker wrote:
On 01/17/2013 03:58 PM, Pádraig Brady wrote:
I Just noticed another option from BSD:
-t threshold
Display only entries for which size exceeds threshold. If
threshold is negative, display only entries for which size is
less than the absolute value of threshold.
I slightly prefer --min-size and --max-size,
though not at the expense of losing the opportunity
to increase compat between these tools.
I suppose we could rename --size to --threshold too.
It seems there are many ways - like always. ;-)
I think --min-size/--max-size has a functional plus over one
single new option. But increasing compatibility to BSD is tempting.
If I'd be asked to decide between --size and --threshold then
the latter is the winner: a) BSD compat, b) the abbreviation
of the option better fits into the already existing ones,
see --size vs. --si, while --th is (currently) fine.
I'll change the patch towards --threshold then. WDYT?
+1
I don't think adding extra --{min,max}-size options are worth it.
My 2 pennies, might be off/new topic.
I am often looking for greatest N files/directories in size. For
instance when partition is nearly full then the line I write is
du -max /var/ | sort -n | tail -10
In my fantasy world there would be new long only option in du doing the same.
du -hax --top=10 # the 10 could be default when optional option is not defined.
That would answer to the question I often have in mind; what is
filling the disk?
I am not sure would I ever remember to use --min-size && --max-size du
options. The find command does excellent job for that purpose, and
it's burned into at least to my memory as a utility to do that job.
Another drawback with --max-size is that when I am interested what is
filling disk I need to guess a limit. If I get it wrong the listing is
either very long or nothing, and rerun is required. The guess
iteration loop can be avoided if --top is present.