<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 11, 2023 at 8:38 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/11/23 15:24, enh via Toybox wrote:<br>
> it occurs to me we could have the best of both worlds if we check the final<br>
> character of the argument? if it's a digit, use the multiplier; if it's not,<br>
> assume the user already gave their preferred multiplier (and didn't mean "8k<br>
> KiB" or "8m KiB" or whatever). even seems to make sense for the 512-byte pipe<br>
> sizes? want me to send another patch on top of this?<br>
<br>
I opened a window with this yesterday but haven't done much with it because I<br>
haven't quite wrapped my head around the design/ui issue at stake. Compatibility<br>
with bash: great. Randomly varying units: less great. </blockquote><div><br></div><div>yeah, i think that's the real trade-off here. "which matters more?"</div><div><br></div><div>and like i said, the bug report i got wasn't "be like bash", it was "be self-consistent".</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(Also this first entry in<br>
your new table RLIMIT_CORE says (block) but has a unit of 1024 which is neither<br>
512 nor 4096 so it's... thousands of blocks? </blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also you're multiplying the units<br>
AFTER capping the input range at LONG_MAX...)<br></blockquote><div><br></div><div>yeah, that's a bug :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yes, _default_ units (when there's no unit specified on the input) makes (a<br>
certain amount of) sense and is easy to detect. Supplied units would override<br>
those instead of stacking. </blockquote><div><br></div><div>(yes, if that's not what i said, it's what i meant to say.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I was also pondering about putting units on the<br>
output but "-l" saying "64k" suddenly gives consumers something else to parse<br>
that's not good, so maybe some "all output is in bytes" command option would<br>
still be good...<br></blockquote><div><br></div><div>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".)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, the RLIMIT_BLAH macros in asm-generic.h go from 0 to 15 in a fixed order,<br>
so just defining the table entries in that order (and reordering the flags to be<br>
in that order) makes a chunk of the logic drop out...<br>
<br>
Hence why I left the window open... :)<br>
<br>
Rob<br>
</blockquote></div></div>