From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9117 invoked from network); 10 May 2002 12:36:46 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 10 May 2002 12:36:46 -0000 Received: (qmail 14294 invoked by alias); 10 May 2002 12:36:20 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 4954 Received: (qmail 14283 invoked from network); 10 May 2002 12:36:19 -0000 X-VirusChecked: Checked Date: Fri, 10 May 2002 13:35:50 +0100 From: Oliver Kiddle To: Zsh users list Subject: Re: umlimit and /etc/zshenv Message-ID: <20020510123550.GA4281@logica.com> References: <20020510043355.GJ10130@eumel.yoo.net> <18763.1021023606@csr.com> <20020510112647.GB1124@eumel.yoo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020510112647.GB1124@eumel.yoo.net> User-Agent: Mutt/1.3.28i Sender: Oliver Kiddle Thorsten Haude wrote: > 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. Couldn't mutt restore the limit after getting the PGP passphrase? Surely it isn't calling nedit to enter the passphrase because it'd then have the passphrase written in clear to disc anyway. > 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 was just wondering about that as nedit has a getenv(). > - 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. Or set it to zero which is what I do. Whenever I do any debugging I then have a shell function which unlimits it and sets other things like CFLAGS. > - I could redirect ulimits output in /etc/zshenv, but that would > prevent seeing other, maybe more serious errors. Probably not a bad idea though. It is generally wise to avoid any output in .zshenv/zshrc as it can mess up quite a few things like this (rcp for instance). If you don't want to lose the errors, you could redirect to a file instead. > - 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 like that idea because it is useful to be able to see things coming back from stderr in nedit shell comands. I wouldn't object if nedit passed the stderr output from the shell command on to its own stderr though. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.