From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY, URI_NOVOWEL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19133 invoked from network); 25 Nov 2020 00:35:36 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2020 00:35:36 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1606264536; b=0+DrUO5D4kvZEwmFbW5fqkuwRkl7QvyP5vvKPr+R0OCWIQHp40J10J1GmuYYsP+/qXldvnca8d lMewJO43G2X+6GOXW+wHDoRI2XZEWsJRdKy4OKod4WSPgXRi7KBTJhRecIUcznoUrYyEzYYFZv zCS6NYzzHeuE8YyWLQVkg3Xrs5FCKUaHeNp89vONixhcrabte/sPKFq59Lq+cU0VK0dkuxyaFY QvhCh6NZ21QzsXmKA7HNGg3bn6wSm2FhVSYEZc6DsrROQn+Gw0tvEskBQ9Jr1LEr4nSQaSjkyP 9lNLjZ3RC02R9hvM8Le7NvzrbVBHP6KNqQEXYrSQ881Khw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (wout4-smtp.messagingengine.com) smtp.remote-ip=64.147.123.20; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1606264536; bh=stPa+PwN0wBS5aIr8Pi5Uh9XMkwKE3xDUwFAMzeFzHM=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:DKIM-Signature:DKIM-Signature:DKIM-Signature; b=ItWD6KaEBP8z+Vue/Yq4wJD1fS/9zQBAo6OdlCbhLokT4JCNtGQs6FfnT3aXFXviLKmwLDcYL7 uEepPmF5hnE7+O+XHKuElpkOELppyKJHbTRrVWYENuwFS46vEiMbiFxdOEW6YMFqInw4E/eXNT zWvIJ+VmtAyFfDEt+xZpyg/EjZxD6etPDio8fJaq8vSZCm4S8mTgqrO4o9atjpLtXJtHOzQ4CD ph4gWZz5Og2O5uofNFsY8+RQ4Ce/4oyrnuZODvutwjEXgY1J6ftNl9G87RCGysWOmPqiRjiyYX IyZ4ymvHa5rQRU7SsSzxDZphVETO1TUxgi0lgRhBxhIPeQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:To:From:Date:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=l95o+KGyDrMahOe47lF2WftSLxb92L+zvxTh3qXMO6I=; b=TX+/y01yqY5bkRWR8VE5qDsYCJ wKrFlB2jhuURdUXuyUOB0TMtFL0IENTlXe/bXardG4cyd3iZgezc9apaKrhkb/1RSiZgCdo5D20Xy 9qJz9GiUYni+Pi9SAEFiAelFtXZDZ/neiImReEP6c8IfEoBdRzC5gf84a3gK2xY9CvWlD7z8znI3x wryzKVXmeI3U3dT6fEDgbU54eaNOpJWJ5X68RqSm1R9mB955JLbjFv7YGzegAoRljf/DY81qcOMvI glIeD/1S+0yqIByCtpxWlnQCn94wxrGFMdud9A+YG54lCs35m7yF0iC2yk46/PIDuq7tuahHG4e5P b+JObSaA==; Received: from authenticated user by zero.zsh.org with local id 1khimS-000Ho2-OF; Wed, 25 Nov 2020 00:35:32 +0000 Authentication-Results: zsh.org; iprev=pass (wout4-smtp.messagingengine.com) smtp.remote-ip=64.147.123.20; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:34235) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1khimD-000Heb-H1; Wed, 25 Nov 2020 00:35:18 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8BC91A2E; Tue, 24 Nov 2020 19:35:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 24 Nov 2020 19:35:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:subject:message-id:references :mime-version:content-type:in-reply-to; s=fm1; bh=l95o+KGyDrMahO e47lF2WftSLxb92L+zvxTh3qXMO6I=; b=YkWZtvzigVJICwFNtMMWTpMayBWlpX t0f7lJVapv3c4s4DvXx5NllsD/k0KFyO4k1P1dnUPz24CLx7rAENa1VXYBbeErlx 4qOgnJnVB8A2BtlLRGpeMLur77ye+XyMUvzVjdK7/Ly8WpC18U2h562/b57wvOQa TgqW1KjJIzzSusxxj9b1zFXaThGMBsL5mZ8VMqNrBM3j8fwaoYoqzkTXFjMClUhV ZziLAPmydTfVNJeHwOTdmPkuSSwci4i4WvRPNdzl1uI97iDcBp+k29ynOwHEHyHt ZqHVlrdm80K1UaBtHHTbeAL+iXe35lVPkwomFsUhqZKKsiv1pqIqQomw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=l95o+K GyDrMahOe47lF2WftSLxb92L+zvxTh3qXMO6I=; b=l9IgO3I4G1xaOP8XOZxmrP XOufDc41lBhuF5PMvY4X7iRHxBmivTr+e+kInl2kDHfz8xrNPBAtox5KiU1b7Up+ 0ZmkbvXwDQ3JoSXQDGWUC8qJ0VVMwQl+Ey3Z9F8z6FbyljrxC3qrZINE3SKxHUGq 1uVEQHZxmQ5XpsgrGvWq+fvxWDasfrp/4azqPVFFOvLCakIReoB8vADcc7mumfzP nwKc63zE9PD91LxWIzjsOfak1AOSdDBp1m08lMg3VuV9uT90Y31OQc5p/ex184Rw k3yEosOa5h2O14Wo/v03MxxfQT1hGWmNO43GR/w6ZljT0n22eac2YeUNPn3aVIbQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegledgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttd dttddtredvnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeevfeetleethfehud eiueejgfejieeutdetgfdvgfduvdekhfduheefhfetkefgleenucffohhmrghinheprghu shhtihhnghhrohhuphgsuhhgshdrnhgvthenucfkphepjeelrddukedtrdeikedrudefhe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhs segurghnihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Received: from tarpaulin.shahaf.local2 (bzq-79-180-68-135.red.bezeqint.net [79.180.68.135]) by mail.messagingengine.com (Postfix) with ESMTPA id 8840B328005E for ; Tue, 24 Nov 2020 19:35:14 -0500 (EST) Received: by tarpaulin.shahaf.local2 (Postfix, from userid 1005) id 4Cghk85qCtz1lt; Wed, 25 Nov 2020 00:35:12 +0000 (UTC) Date: Wed, 25 Nov 2020 00:35:12 +0000 From: Daniel Shahaf To: Zsh hackers list Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc Message-ID: <20201125003512.GC17978@tarpaulin.shahaf.local2> References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Seq: 47618 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Good morning Stephane, Stephane Chazelas wrote on Mon, Nov 23, 2020 at 21:49:42 +0000: > BTW, POSIX is currently looking at extending the "ulimit" > builtin specification > (https://www.austingroupbugs.net/view.php?id=1418) which is what > got me looking in the first place. I think zsh is mostly > compliant with their currently proposed resolution. Thanks for the heads-up. > I found a small issue in the "limit" builtin in that for instance > "limit msgqueue 1M" sets that limit to 1 byte instead of 1MiB > (that M suffix is silently ignored) and that "limit msgqueue 10" > was not following documentation and tried to have a go at > addressing it, but ended up finding a few more small issues, > went down the rabbit hole, also trying to address the problem > (not specific to zsh) that you never know what unit those > resource limits are meant to be expressed as. > From 5c1971d40b238edb1a745b7298b0169cff2b8053 Mon Sep 17 00:00:00 2001 > From: Stephane Chazelas > Date: Mon, 23 Nov 2020 17:31:02 +0000 > Subject: [PATCH] improve limit/ulimit API and documentation > > A few issues addressed: > This patch is over 1k lines long and makes multiple independent changes. Could you please split this into one patch per logical change? That would make it easier to review, both now, and in the future should a regression be bisected to it. Thanks, Daniel > * msgqueue limit specifies a number of bytes but was classified as > ZLIMTYPE_NUMBER which meant k/m suffixes were not allowed and the > default unit for `limit` was 1 (byte) instead of the 1024 (KiB) > specified by documentation. > > -> turns out tcsh's `limit` handled that limit (called `maxmessage` > there) the same way and `bash`, `bosh` and `mksh`'s `ulimit` (not > ksh93 which takes kibibytes there) also expect a number of bytes > there. > > So, the type was changed to ZLIMTYPE_MEMORY, but the unit remains > bytes for both `limit` and `ulimit` as a (now documented) special > quirk for backward compatibility. > > * unit suffixes, where not supported (like for ZLIMTYPE_NUMBER) are > silently ignored. > > -> now return an error on unexpected or unrecognised suffixes. > > * limit output using ambigous kB, MB units. These days, those tend to > imply decimal scaling factors (1000B, 1000000B). > > -> changed output to use KiB, MiB, the ISO 80000 unambiguous ones > which are now more or less mainstream. > -> those, extended to KMGTPE..iB are also accepted on input while > KB, MB... are interpreted as decimal. (K, M, G remain binary). > -> documentation updated to avoid kilobyte, megabyte and use > unambiguous kibibyte, mebibyte... instead. > > -> rt_time limit is now `ulimit -R` like in bash or bosh. > > * "nice" limit description ("max nice") was misleading as it's more > linked to the *minimum* niceness the process can get. > > -> Changed to "max nice priority" matching the Linux kernel's own > description. > > * documentation for both `limit` and `ulimit` missing a few limits -> > added > > * time limits are output as h:mm:ss but that's not accepted on input. > 1:00:00 silently truncated to 1:00 (one minute instead of one hour). > > -> accept [[hh:]mm:]ss[.usec] > > * limit and ulimit output truncate precision (1000B limit represented as > 0kB and 1 respectively) > > -> addressed in `limit` but not `ulimit` (where > compliance/compatibility with ksh matters). By only using scaling > factors when the limit can be represented in an integer number of > them (using B, as in 1000B above when none qualify). > > * some limits can't be set to arbitrary values (like that 1000 above for > filesize) and it's not always obvious what the default unit should be. > > -> recognise the B suffix on input for "memory" type limits and > "s"/"ms"/"ns" for time/microsecond type units so the user can input > values unambiguously. > -> those suffixes are now recognised by both limit and ulimit. Parsing > code factorised into `zstrtorlimt`. > > * `limit` and `unlimit` are disabled when zsh is started in csh > emulation even though those builtins come from there. > > -> changed the features_emu in rlimits.mdd (only used there) and > mkbltnmlst.sh to features_posix for those to only be disabled > in sh/ksh emulation. > > * `limit` changes the limits for children, `ulimit` for the shell, > but both report limits for children, and it's not possible to > retrieve the shell's own limits. > > -> ulimit not changed as it's probably better that way. > -> `limit -s somelimit` changed so it reports the somelimit value > for the shell process > > -> documentation improved. > --- > Doc/Zsh/builtins.yo | 129 +++++++++---- > Doc/Zsh/expn.yo | 18 +- > Doc/Zsh/mod_zpty.yo | 4 +- > Doc/Zsh/params.yo | 10 +- > NEWS | 7 + > Src/Builtins/rlimits.c | 390 +++++++++++++++++++++++++++------------ > Src/Builtins/rlimits.mdd | 8 +- > Src/mkbltnmlst.sh | 10 +- > Test/B12limit.ztst | 129 +++++++++++++ > 9 files changed, 530 insertions(+), 175 deletions(-) > > Though I think it could be applied as is (I don't think I've > broken backward compatibility), there are a few things I'm not > completely happy or sure about so I'd appreciate some input. > > The few remaining issues I've not really addressed here: > > - ulimit output rounds down the values (some of them anyway) so > we lose information. Is it worth addressing? (like with a > "raw" option)? > > - Some might disapprove the switch to kibibyte/mebibyte KiK/MiB > (and the MB meaning 1,000,000). > > - Is it worth accepting floating point values like: > limit filesize 1.2G > > - I've only tested it on Ubuntu, FreeBSD and Cygwin. I suspect > my test cases will fail on 32bit systems. They're skipped on > Cygwin which doesn't let you set any limit AFAICT. I don't > have much coverage in those two tests, but with limits being > very system specific, I'm not sure how to tackle it. > > - ulimit still outputs the limits set for children processes. I > think that's probably best. So it outputs the limits set by > limit, ulimit or ulimit -s, even if strictly speaking, it > doesn't give you what's returned by getrlimit() like in other > shells (that only ever becomes visible if you use "limit" > anyway which is not in those other shells. > > - there are some corner case issues that could surprise users > and may be worth documenting like: > (limit filesize 1k; (print {1..2000} > file)) still creates a > 8K file because the fork for the (print...) was optimised out > so the limits are not applied. > > - I've made it so "limit -s filesize" reports the shell's own > limit (-s is for "set" initially, but it could also be "shell" > or "self"). But while "limit" outputs all children limits, > "limit -s" still copies those children limits to the shell's > and there's no way to print *all* self limits. That doesn't > make for a very intuitive API.