[Toybox] [PATCH] ulimit: actually use the units we claim.

[enh]

On Thu, May 11, 2023 at 8:38 PM Rob Landley <rob at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230512/dfab12d0/attachment.htm>