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: > 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'? 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. Have a nice day, Berny
