[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #46815] problem when testing file size
From: |
Martin Steigerwald |
Subject: |
Re: [bug #46815] problem when testing file size |
Date: |
Wed, 13 Jan 2016 11:35:11 +0100 |
User-agent: |
KMail/5.1.53 (Linux/4.4.0-tp520-btrfstrim+; KDE/5.19.0; x86_64; git-cd3992a; 2016-01-10) |
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 ***
- [bug #46815] problem when testing file size, anonymous, 2016/01/05
- [bug #46815] problem when testing file size, James Youngman, 2016/01/05
- [bug #46815] problem when testing file size, anonymous, 2016/01/08
- [bug #46815] problem when testing file size, Dale Worley, 2016/01/08
- [bug #46815] problem when testing file size, James Youngman, 2016/01/09
- Re: [bug #46815] problem when testing file size, Bernhard Voelker, 2016/01/10
- Re: [bug #46815] problem when testing file size, James Youngman, 2016/01/10
- Re: [bug #46815] problem when testing file size, Assaf Gordon, 2016/01/10
- Re: [bug #46815] problem when testing file size, Bernhard Voelker, 2016/01/10
- Re: [bug #46815] problem when testing file size,
Martin Steigerwald <=
- Re: [bug #46815] problem when testing file size, Martin Steigerwald, 2016/01/13