From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10596 invoked by alias); 6 Oct 2014 13:23:30 -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: 33364 Received: (qmail 28968 invoked from network); 6 Oct 2014 13:23:26 -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-b7f156d0000063c7-cb-543297cbf598 Date: Mon, 06 Oct 2014 14:23:22 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: ulimit behaviour of bash vs. zsh Message-id: <20141006142322.6bb84db0@pwslap01u.europe.root.pri> In-reply-to: <2014-10-06T14-23-03@devnull.michael-prokop.at> References: <2014-10-06T14-23-03@devnull.michael-prokop.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+NgFupmluLIzCtJLcpLzFFi42I5/e/4Zd3T041CDHae5rc42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGecX1xUs5a74u+A4YwPjM44uRk4OCQETiTXXNzNB2GISF+6t Z+ti5OIQEljKKNH+eAozhLOcSeLzzTZWkCoWAVWJ1ZuXM4PYbAKGElM3zWYEsUUExCXOrj3P 0sXIwSEsoCtxfH85SJhXwF7i35vPYAs4BWwkdszfwQ5iCwlYSyzafAmslV9AX+Lq309QR9hL zLxyhhGiV1Dix+R7LCA2s4CWxOZtTawQtrzE5jVvmScwCsxCUjYLSdksJGULGJlXMYqmliYX FCel5xrqFSfmFpfmpesl5+duYoQE4JcdjIuPWR1iFOBgVOLhjdhhGCLEmlhWXJl7iFGCg1lJ hPf3VKMQId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYyCp8J+CZ+cmBBg4Fgxuf1rkNu2DYe2dn2w mmH/tZWt6MHcsuhv9R2zjx9copNmZvJ1fkEY78pFnpwJRzfqfdguOCs640Jf1E/jAq9+f9k5 ucWPdbeoNL82WnPv9I/klm2GtZN4ubc5+9dunuu+3d/XJl0r+2Sf0OJbWXq3faqYfllNSY16 KqvEUpyRaKjFXFScCAB9iiUsHgIAAA== On Mon, 06 Oct 2014 14:30:46 +0200 Michael Prokop wrote: > this is what Bash does: > > $ ulimit -l > 64 > $ ulimit -l unlimited > bash: ulimit: max locked memory: cannot modify limit: Operation not permitted > $ echo $? > 1 > > While that's the behaviour of Zsh: > > % ulimit -l > 64 > % ulimit -l unlimited > % echo $? > 0 > % ulimit -l > 64 > > I find this quite irritating. Is that behaviour by intention? :) I think it might be, but it's a little obscure and took some tracking down. It turns out if you set a soft limit to unlimited the shell is smart / overdesigned enough to know that the maximum you can actually set it to successfully is the value of the hard limit, so it silently downgrades your "unlimited" request to the maximum you can actually get. (Line 670 of Src/Builtins/rlimits.c for those following along not at home; line 652 does the same if the limit isn't known by name/letter. Whether setting the internal limits structure before a system call that may fail is also problematic I don't know.) Why I'm not sure it's intentional is the documentation says there's a special value "hard" to set the limit to the value of the hard limit; it says nothing about do this with the value "unlimited" that I can see. This bypasses a lot of internal shell logic but ends up doing roughly the same thing. I suppose it could at least warn about this. pws