Re: [bug #46815] problem when testing file size

[Martin Steigerwald]

Am Montag, 11. Januar 2016, 02:29:24 CET schrieb Bernhard Voelker:
> On 01/11/2016 12:43 AM, Assaf Gordon wrote:
> >> Suppose someone wants to find files smaller than 20MiB.  Are you sure
> >> that the best answer we should give them is that they should use
> >> "find -size -20971520c"?
> 
> Although this is inconvenient, there are several ways for the user to
> avoid doing the math himself.
> 
>   # shell arithmetic expansion
>   find -size -$((20*1024*1024))c
> 
>   # using bc(1)
>   find -size -`echo '20*1024*1024' | bc`c
>   find -size -$( bc<<<'20*1024*1024' )c
> 
>   # using expr(1)
>   find -size -$(expr 20 '*' 1024 '*' 1024)c
> 
>   # Alternative tools, e.g. du(1)
>   du -a --threshold=-20MiB
> 
> There are various ways, but I admit that the user intuitively would
> maybe want to use the M, G or Tib suffixes.
> 
> So the solution is either to combine 'M' and 'c'
>   find -size -20Mc
> which would be fully backward compatible, or go the way Assaf suggests
> and change the meaning of the suffixes M and G:

Not completely obvious, but if documented, I´d say I find this agreeable.

My other suggestion back then was to use the "-size " options but new
ways to specify less than, greather than or equal. I think I mentioned
it in the bug report already. Like:

find -size lt 20M

find -size gt 20M

find -size eq 20M

Advantage of this one: This concept is known to shell users already from
the test command.

So it would use byte comparison with this new operatores, but act like
before with the old ones.

> > With this patch, when using "-size" with K/M/G suffixes *and*
> > greater-than/less-than option behave as if the block-size is 1
> > and the user entered the explicit byte value?
> 
> I'd guess that the k, M and G suffixes are not very often used
> in scripts - because they didn't "work as expected".
> Furthermore, many other GNU tools allow using more fine-grained control
> over parameter values using xstrtoimax()-style: different suffixes
> (20M alias 20Mib, and 20MB), and a wider range of SI suffixes
> (K,M,G,T,P,E,Z,Y).
> I must confess I like Assaf's idea, leaving 512-blocks for 'b' (with the
> rounding as mandated by POSIX), and otherwise using byte granularity
> with proper SI suffixes.
> 
> Another topic is file size of sparse files (like du's --apparent-size
> option); maybe something like '-size address@hidden'?

A nice idea to have this as well.

> Thus said, a new option could fix all the things for the user, but
> I'm convinced that it could all be done with -size, too.

I also suggest to coordinate this with any adaption for the time
comparision switches for some consitency, at least in case you decide for
eq, lt, gt operators:

bug #37110: find: alternative time handling
https://savannah.gnu.org/bugs/?func=detailitem&item_id=37110

Thanks,


-- 
Martin Steigerwald  | Consultant / Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: address@hidden | web:  http://www.teamix.de | blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***