On Wed, Dec 11, 2019 at 11:41 AM Rob Landley <[email protected]> wrote: > > > > On 12/10/19 6:47 PM, enh wrote: > > if i saw someone trying to use that, i'd assume that they were digging > > themselves into an unnecessary hole... in fact, the only time i > > remember seeing anyone try to use --apparent-size we talked them out > > of it. > > > > that said --- du tests that used --apparent-size would probably work > > on all kinds of filesystems that the current tests don't work on. > > $ stat -c%s toys.h > 3440
yeah, i was thinking yesterday that even if you did want `du -b` as a "show me the size in bytes, a tab, and the filename of all files", that's just find . -type f -printf "%s\t%p\n" which toybox already does just fine. > > (so > > maybe implementing --apparent-size and -B# wouldn't be so silly, and > > then -b could just turn those on?) > > "Is this one simple option worth it?" > > "You could add two more options to justify this one." > > I'll take that as a no. mission accomplished! > > i'm assuming the busybox request didn't come with a convincing use case? > > No, but I was using it as an indicator that somebody somewhere missed its > absence. like i said, the only time i've seen anyone try to go down this route, they were holding it wrong :-) > > (there are still Android devices with *only* 32-bit userspace. > > everything low-end is that, even though there are no 32-bit SoCs, and > > afaik everyone's using a 64-bit *kernel* at least.) > > Indeed. The x32 target was created because smaller pointer sizes mean less > stack > space and better CPU cache and memory bus bandwidth utilization. > > And in the embedded space, 32 bits is often a luxury. (One of our taglines for > j-core is "32 bits for the price of 8", although "price" here is circuitry > size > in your design. We'd need waaaaaaay more volume to get the costs down to "3 > cent > chip" territory.) > > Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
