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=0.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RDNS_NONE, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kivPc-000K4Y-HQ; Sat, 28 Nov 2020 08:16:56 +0000 Authentication-Results: zsh.org; iprev=pass (relay9-d.mail.gandi.net) smtp.remote-ip=217.70.183.199; dmarc=none header.from=chazelas.org; arc=none Received: from relay9-d.mail.gandi.net ([217.70.183.199]:45693) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kivPG-000Jqe-Tr; Sat, 28 Nov 2020 08:16:35 +0000 X-Originating-IP: 94.10.124.211 Received: from chazelas.org (unknown [94.10.124.211]) (Authenticated sender: stephane@chazelas.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id A9420FF808; Sat, 28 Nov 2020 08:16:33 +0000 (UTC) Date: Sat, 28 Nov 2020 08:16:32 +0000 From: Stephane Chazelas To: Daniel Shahaf , Zsh hackers list Subject: Re: [PATCHv3 2/2] [long] improvements to limit/ulimit API and doc (the rest) Message-ID: <20201128081632.7m4fd5bbxghyvzug@chazelas.org> Mail-Followup-To: Daniel Shahaf , Zsh hackers list References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org> <74327-1606347813.918593@HxCz.NV4p.AwzH> <20201126205819.dbncs24ppnw3pdny@chazelas.org> <20201127163949.GD26720@tarpaulin.shahaf.local2> <20201127201342.t4uthqbfwuhzgevz@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201127201342.t4uthqbfwuhzgevz@chazelas.org> X-Seq: 47691 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: [sorry, should have been v3 in the subject of the email I'm replying to by the way). 2020-11-27 20:13:42 +0000, Stephane Chazelas: [...] > I've tried to address that in this v3 patch. Specifying the type > (as in char*, int...) seems redundant though and not generally > done in other functions, so I've left it out for now. [...] > + if (shell) { > + /* > + * FIXME: this is dead code as at the moment, there is no API > + * for the user can request all limits *of the shell* be > + * displayed. > + * > + * Should we add a "limit -s -a" or "limit -s all"? > + */ [...] And in my initial email: > - 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. Maybe one approach could be to introduce some $shell_limits and $children_limits special associative arrays indexed on limit name (or number for those limits that don't have a name yet). Which would allow things like: (( shell_limits[filesize] >= min )) || die "can't do" There's the problem of RLIM_INFINITY and the fact that rlim_t is unsigned so if 64bit, allows values beyond the integer ones supported by arithmetic evaluation. Both could be addressed by making the value a floating point number (append a . or e0 and use inf for RLIM_INFINITY), but that sounds less than ideal as we're losing precision and limits are really integers in the first place (and for consistency limit/ulimit would need to be updated to accept floating point on input). There's also the problem that "limit" (contrary to ulimit) lets you set more than one limit at a time, but not print more than one limit at a time ("limit cputime" prints the value of "cputime" but "limit cputime filesize" tries to set the cputime limit to "filesize"). So, maybe a better approach is to add a "-p" for "print": - limit or limit -p prints all the known limits for children - limit -ps prints all the known limits for the shell - limit -p filesize or limit filesize prints the filesize limit - limit -p filesize cputime prints the filesize and cputime limits. And maybe a "-r" for "raw" though there's always the problem of RLIM_INFINITY and uint64. And of course there's always the possibility of ignoring the problem altogether as it's not as if anybody is going to miss that feature very badly. At the moment, one can always do: (( ${$(ulimit -f)//unlimited/inf} >= ceil(min / 512.) )) || die "can't do" (though that's children_limits, and bearing in mind that ulimit rounds down the number so we'll get false positives like when min is 1 and the limit is 511B, rounded down to 0). -- Stephane