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 <e...@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(-) > >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
