On 5/11/23 15:24, enh via Toybox wrote: > it occurs to me we could have the best of both worlds if we check the final > character of the argument? if it's a digit, use the multiplier; if it's not, > assume the user already gave their preferred multiplier (and didn't mean "8k > KiB" or "8m KiB" or whatever). even seems to make sense for the 512-byte pipe > sizes? want me to send another patch on top of this?
I opened a window with this yesterday but haven't done much with it because I haven't quite wrapped my head around the design/ui issue at stake. Compatibility with bash: great. Randomly varying units: less great. (Also this first entry in your new table RLIMIT_CORE says (block) but has a unit of 1024 which is neither 512 nor 4096 so it's... thousands of blocks? Also you're multiplying the units AFTER capping the input range at LONG_MAX...) Yes, _default_ units (when there's no unit specified on the input) makes (a certain amount of) sense and is easy to detect. Supplied units would override those instead of stacking. I was also pondering about putting units on the output but "-l" saying "64k" suddenly gives consumers something else to parse that's not good, so maybe some "all output is in bytes" command option would still be good... Also, the RLIMIT_BLAH macros in asm-generic.h go from 0 to 15 in a fixed order, so just defining the table entries in that order (and reordering the flags to be in that order) makes a chunk of the logic drop out... Hence why I left the window open... :) Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
