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

[enh]

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?

On Wed, May 10, 2023 at 6:11 PM enh <enh at google.com> wrote:

> It's my fault that toybox ulimit claim units but doesn't use them; I
> added them to match bash without noticing that the kernel always uses
> bytes. I'm assuming we want to resolve that in favor of actually honoring
> the units, and removing that from the known differences from bash, but I
> don't have a strong opinion (other than that we should be
> self-consistent).
>
> One thing that's awkward now is that `ulimit -s 16m` used to do what
> you'd expect, but now gives you 1024 times that. Given a clean slate,
> I'd say "bytes are obviously the right choice for input, and toybox
> already transparently lets you choose your own multipliers". But it
> seems odd that `ulimit -s 8192` would mean different things to bash or
> toybox sh?
>
> I've added a couple of other existing differences to the list of bash
> deviations, but not fixed them in this patch because the obvious fix would
> make the diff unreadable (and because I only noticed those differences
> playing around on the command line to test this --- no-one else has
> noticed yet, that I know).
> ---
>  toys/posix/ulimit.c | 62 +++++++++++++++++++++++++++------------------
>  1 file changed, 38 insertions(+), 24 deletions(-)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230511/7c68114b/attachment.htm>