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 -@20M'? 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: martin.steigerw...@teamix.de | 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 ***
