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.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY,URI_NOVOWEL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27968 invoked from network); 25 Nov 2020 06:45:06 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2020 06:45:06 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1606286706; b=kBuwm8Xp57QNhMuGtPvPprfMr9s+DXvhNIIW5/l6u/SD9hYj8+sU9c6GT0CoJGUomUikR2CUUu ym7naP0DHY1oOUTHupP473WfQ9KFA+S/43MqEz55wXT/HOKVgLZLH82T65kg+GdsH3NdTIpqw5 apPX4PGv+I/WBwhBGyCC36dgN0767nKfrY6bzoSNKOh7MXtk9cJwnDqagkkQ51k+jOhtDxONAS 6K6YznUPzJFXOeTb1W+bLP0sgnooTOjMwfsxpzvFQFB0LuGWDCxBOiugR1EIX/QUELGU/ytajE hMF8ZJ8EAXMq+dF0CNXbAigG1+Rm5Qu9zgILPqJM22PZww==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (relay1-d.mail.gandi.net) smtp.remote-ip=217.70.183.193; dmarc=none header.from=chazelas.org; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1606286706; bh=w11cbNROunJPf7ykaMo2C0ddhLCmGFg4A1V/y8VFWU0=; 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:Cc:To:From:Date:DKIM-Signature; b=AdGkiYMoNsx2bKm8eStfjjsOueW7XcGmcIWx3j0uKcjK0GWlO7fCsNsNQ/E7IX9WAsuv/vWG77 68bQB2GjeYcF4F1XXdrKv/K1zg2cBGG2raHn0EAJVlTkKcm0U1mXJiUzz/8qv7o8C3bCZBbalK WMvNeIhgGtFDr1eBtAXxJe77bF2Dh8dcvhockOwoKY2yaRrl9jWgRyeP1WPDGekwBH3CJ3u82C 8mU2OaCEEio8qdii//+3zJpz6nicQ70cH0Gu1tpMjMqCyPEYmOB9zaroRD97b07eeOIRTdp5JW DoJMXt8uKguwgXwFvx2vCq5J0IWtW3EHz2QLtKYeZi/x7Q==; 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:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=36lC6G4fBiUPlakobTX8qXyLcE/9fida5iSDg36MTm8=; b=eIh5H7Fa1Oy/1iJTw2nAdQBR9j fERhr77am/EnXRhTex6v7iYP6TGExuBmfy4AAclmRELpe/4xzEOlY9fWRXflRMC8PpLglIn2pDFiv T5i8JmUwpYNQWgwWuWHow+BWxN3t0pDL1lPFUxJtfJafe2Cjeqpf3Tf+rBGl5AjdDlrmVuCXNgMPT wkO3Wx11yMQv+EOmNwQK80zluF/qARt+P9ZChTlVTcwIWeofe/O4TAMubsnxBQGUfzlCLCaKmqW/u sgjDK1w56EvYeBDYjF7l+JlbYbc7TzmQW5OEZX5e85h9EiJ55oKocVkHUpesUOvM+VAeKndfNX0cx re+2RHBg==; Received: from authenticated user by zero.zsh.org with local id 1khoY3-000ALo-9j; Wed, 25 Nov 2020 06:45:03 +0000 Authentication-Results: zsh.org; iprev=pass (relay1-d.mail.gandi.net) smtp.remote-ip=217.70.183.193; dmarc=none header.from=chazelas.org; arc=none Received: from relay1-d.mail.gandi.net ([217.70.183.193]:31943) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1khoXm-000A6Z-2x; Wed, 25 Nov 2020 06:44:46 +0000 X-Originating-IP: 94.10.124.211 Received: from chazelas.org (unknown [94.10.124.211]) (Authenticated sender: stephane@chazelas.org) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 55B3F24000A; Wed, 25 Nov 2020 06:44:43 +0000 (UTC) Date: Wed, 25 Nov 2020 06:44:43 +0000 From: Stephane Chazelas To: Daniel Shahaf Cc: Zsh hackers list Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc Message-ID: <20201125064443.a6zdrwka2ajkgb2t@chazelas.org> Mail-Followup-To: Daniel Shahaf , Zsh hackers list References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org> <20201125003512.GC17978@tarpaulin.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201125003512.GC17978@tarpaulin.shahaf.local2> X-Seq: 47621 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: 2020-11-25 00:35:12 +0000, Daniel Shahaf: [...] > > 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. [...] Hi Daniel, thanks for having looking into it. They're not independent, except maybe for the "limit"/"unlimit" now back in csh which is a 5 code line change. Chunks of the code and doc have been rewritten to address those. Separating out the changes would mean rewriting the code several times which would be more effort for me and reviewers, mostly wasted if we're only keeping the last iteration. But maybe before looking in detail at the code, we can discuss whether the change in API makes sense. > > * 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. >