On Thu, May 11, 2023 at 8:38 PM Rob Landley <r...@landley.net> wrote:
> 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. yeah, i think that's the real trade-off here. "which matters more?" and like i said, the bug report i got wasn't "be like bash", it was "be self-consistent". like i said: given a clean slate, i'd have the inputs unscaled (and lean on toybox's "you can use si suffixes anywhere" to be _more_ convenient than bash's "fixed suffix, mostly too small these days"). and for output, i'd be tempted to use the "human readable" function. even on my _phones_ KiB isn't really helpful; MiB would be better. > (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? that seemed to be what bash was doing? (i noticed that afaict bash is just outputting a fixed "8" for the pipe sizes too, but i think we've had that discussion before, and that seems like bash behavior _not_ to copy.) > Also you're multiplying the units > AFTER capping the input range at LONG_MAX...) > yeah, that's a bug :-) > 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. (yes, if that's not what i said, it's what i meant to say.) > 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... > yeah, or the other way round to match the -h on other tools? (i'm torn between "i think i'd always want the human-readable output" and "consistency with other tools".) > 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