From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18498 invoked by alias); 24 Jun 2014 15:17:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32791 Received: (qmail 18872 invoked from network); 24 Jun 2014 15:17:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7fac6d000006cfe-38-53a9941d2ce5 Date: Tue, 24 Jun 2014 16:07:08 +0100 From: Peter Stephenson To: Thomas Klausner , zsh-workers@zsh.org Subject: Re: ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh] Message-id: <20140624160708.6bef4d2c@pwslap01u.europe.root.pri> In-reply-to: <20140624143711.GG13765@danbala.tuwien.ac.at> References: <20120816132053.GJ2428@danbala.tuwien.ac.at> <20120816142517.188972cd@pwslap01u.europe.root.pri> <20120816142504.GO2428@danbala.tuwien.ac.at> <20120816201848.4b442246@pws-pc.ntlworld.com> <20120817081109.GU2428@danbala.tuwien.ac.at> <20120817103803.73f82242@pwslap01u.europe.root.pri> <20120817105019.GB2428@danbala.tuwien.ac.at> <20120817123535.62ab00a1@pwslap01u.europe.root.pri> <20120817121605.GD2428@danbala.tuwien.ac.at> <20140624143711.GG13765@danbala.tuwien.ac.at> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsVy+t/xq7qyU1YGGyxuNLSY93oxq8XB5odM Dkwevdt/sHusOviBKYApissmJTUnsyy1SN8ugSuj4WM3U8EfgYoD39eyNTDu4uli5OSQEDCR ODvxCzOELSZx4d56ti5GLg4hgaWMErtObWCCcPqZJBoedrKAVLEIqEpMntXJBGKzCRhKTN00 mxHEFhGwkJhx8DvYJGEBR4kJ62eyg9i8AvYSu59OYAOxOQWsJL6tWscKMXQdi8SHZwtYQRL8 AvoSV/9+YoI4w15i5pUzjBDNghI/Jt8DW8wsoCWxeVsTK4QtL7F5zVvmCYwCs5CUzUJSNgtJ 2QJG5lWMoqmlyQXFSem5hnrFibnFpXnpesn5uZsYIaH5ZQfj4mNWhxgFOBiVeHgv7FoRLMSa WFZcmXuIUYKDWUmE17R7ZbAQb0piZVVqUX58UWlOavEhRiYOTqkGRp1dmU7hvDPWH1494550 Zb7Mq/jKdH/VPC4+yxJ/6fn23a+D10Xs+xJzdPLSmY4z7/O9ejYjb8q7B9re2grWfAdZPkTF R5n+jld/YLMpg3u2lP3RV3mbapxEtmUv1X1jvnDW7pNcRer524zZOOMEN706vnTLNO0TlSV7 ZrdYd2pfvr/3+OKf7kosxRmJhlrMRcWJADGm9jorAgAA On Tue, 24 Jun 2014 16:37:11 +0200 Thomas Klausner wrote: > A couple of days ago I noticed that 'ulimit -a' is now different (on > NetBSD-6.99.44/x86_64 with zsh-5.0.5); see in the old mail below what > it looked like before: > > -t: cpu time (seconds) unlimited > -f: file size (blocks) unlimited > -d: data seg size (kbytes) 262144 > -s: stack size (kbytes) 4096 > -c: core file size (blocks) unlimited > -m: resident set size (kbytes) 32485916 > -l: locked-in-memory size (kbytes) 10828638 > -u: processes 160 > -n: file descriptors 128 > -b: socket buffer size (bytes) unlimited > -v: virtual memory size (kbytes) unlimited > -N 11: 160 > > It seems "-r" was replaced with "-N", and no help string is supplied. > > I've also tried zsh git head and see the same issue there. > > You probably know better where to look for this. That means it hasn't identified limit 11 as being associated with what it thinks -r was previously associated with; because it's now a generic limit it just blindly adds it without a help string. Sorry, I don't have access to NetBSD so not only don't I know what the problem is I don't even know that it *is* a problem --- it's a problem if someone thinks -N 11 is the same as -r, in which this needs an appropriate test; or, if -N 11 is new, if that should be associated with some other option. Someone who does know NetBSD will have to tell me what needs doing. In Src/rlimits.c, the only case for handling -r is currently marked as: # ifdef HAVE_RLIMIT_RTPRIO case RLIMIT_RTPRIO: if (head) printf("-r: max rt priority "); break; # endif /* HAVE_RLIMIT_RTPRIO */ Those definitions come from a set of tests in configure.ac loooking like zsh_LIMIT_PRESENT(RLIMIT_RTPRIO) which are basically identical for all limits apart from the name --- they basically look to see if a value for RLIMIT_RTPRIO is defined in the headers. The headers are presumably correct as the other limits are there. pws