<div dir="ltr">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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 10, 2023 at 6:11 PM enh <<a href="mailto:enh@google.com">enh@google.com</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"><div dir="ltr">It's my fault that toybox ulimit claim units but doesn't use them; I<br>added them to match bash without noticing that the kernel always uses<br>bytes. I'm assuming we want to resolve that in favor of actually honoring<br>the units, and removing that from the known differences from bash, but I<br>don't have a strong opinion (other than that we should be<br>self-consistent).<br><br>One thing that's awkward now is that `ulimit -s 16m` used to do what<br>you'd expect, but now gives you 1024 times that. Given a clean slate,<br>I'd say "bytes are obviously the right choice for input, and toybox<br>already transparently lets you choose your own multipliers". But it<br>seems odd that `ulimit -s 8192` would mean different things to bash or<br>toybox sh?<br><br>I've added a couple of other existing differences to the list of bash<br>deviations, but not fixed them in this patch because the obvious fix would<br>make the diff unreadable (and because I only noticed those differences<br>playing around on the command line to test this --- no-one else has<br>noticed yet, that I know).<br>---<br> toys/posix/ulimit.c | 62 +++++++++++++++++++++++++++------------------<br> 1 file changed, 38 insertions(+), 24 deletions(-)<br><br></div>
</blockquote></div>