From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8530 invoked from network); 10 May 2002 11:30:11 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 10 May 2002 11:30:11 -0000 Received: (qmail 3696 invoked by alias); 10 May 2002 11:29:41 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 4953 Received: (qmail 3684 invoked from network); 10 May 2002 11:29:39 -0000 Date: Fri, 10 May 2002 13:26:47 +0200 From: Thorsten Haude To: Zsh users list Subject: Re: umlimit and /etc/zshenv Message-ID: <20020510112647.GB1124@eumel.yoo.net> Mail-Followup-To: Zsh users list References: <20020510043355.GJ10130@eumel.yoo.net> <18763.1021023606@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <18763.1021023606@csr.com> X-Warning: Email may contain unsmilyfied humor and/or satire. Keywords: Eine Botschaft for =?iso-8859-15?Q?Kuriere?= =?iso-8859-15?Q?=3A_Drogen_t=F6ten!?= Organization: Ministry of Information, Department of Information Adjustments User-Agent: Mutt/1.5.0i Hi Peter, * Peter Stephenson [02-05-10 11:40]: >Thorsten Haude wrote: >> I have the following line in my /etc/zshenv: >> ulimit -c 20000 >> >> 1. This is a legacy from the Bash. I read zsh's manpage but couldn't >> find a clear statement about what happens if neither -S nor -H are >> given. >If -H isn't set, soft limits are assumed. The manual page is a little >elliptical, but reading what it doesn't quite say implies this --- -S is >there to allow you to set both types of limit at once. The patch at the >bottom makes this clearer. Thanks for clearing that up. >> 2. I get problems with this command when a process reduces the hard >> limit and calls a subprocess. So I wonder whether I get the semantics >> of /etc/zshenv and ulimit wrong and ulimit should in fact be in >> another /etc/z* file. >> Could someone explain where my error is? >I think you're saying you're reducing the hard limit, and then executing >a command (the one in /etc/zshenv) which tries to make the soft limit >higher than the hard limit. I think that's the correct behaviour --- >there's no way it can increase the value past the hard limit, and zsh >happens to warn you it can't do that when other shells may not (you may >find bash returns status 1 even if it doesn't print anything). > >If this is what is going on, you need to work around it somehow: either >use the output from ulimit or limit to decide what the hard limit is, or >if you're not interested in the error message simply send it to >/dev/null with `2>/dev/null'. That's what I scraped together myself. I don't think one of the applications involved is doing wrong, the result is however that I get an error. To name names: Mutt uses setrlimit() to disable coredumps before handling the PGP passphrase. A macro for NEdit uses a shell command to get an environmental variable. This uses /etc/zshenv of course, the ulimit returns with an error and the macro command does not succeed because the expected result is prepended by ulimit's error output. I could do several things to avoid the error: - Use another macro command, which does not shell out. I already did that, but in general I think the ability to do shell commands in an editor is more than just nice to have. - I could remove the ulimit from /etc/zshenv, but I'm not sure how large cores can get, so I'd rather keep it, and not only for interactive shells. - I could redirect ulimits output in /etc/zshenv, but that would prevent seeing other, maybe more serious errors. - NEdit or Mutt could handle things differrently. But how? Would it be better for NEdit to just ignore stderr when returning results, only evaluating it to show an error? I don't know whether Mutt could do with a soft limit. I just want to learn more about the issues involved in case a similar error is coming up that can't be avoided as easily. Thanks for your help! >> Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist, >> für viel gefährlicher als der, der den Schmutz macht. >> - Kurt Tucholsky >(In case anyone was wondering: in general the people who root out dirt >should be considered much more dangerous than those who make the dirt in >the first place.) No "should", please, Tucholsky has been a journalist: Besides, the one pointing out the dirt is hearabouts considered more dangerously than the one making it. (Tucholsky biography: http://www.infoplease.com/ce6/people/A0849625.html) Thorsten -- Denn ein Tyrann ist nicht, wenn die Masse nicht geduldig stillhält. - Kurt Tucholsky