Zsh Mailing List Archive
Messages sorted by:
Re: umlimit and /etc/zshenv
- X-seq: zsh-users 4953
- From: Thorsten Haude <zsh@xxxxxxxxxxxxxx>
- To: Zsh users list <zsh-users@xxxxxxxxxx>
- Subject: Re: umlimit and /etc/zshenv
- Date: Fri, 10 May 2002 13:26:47 +0200
- In-reply-to: <18763.1021023606@xxxxxxx>
- Keywords: Eine Botschaft for Kuriere: Drogen töten!
- Mail-followup-to: Zsh users list <zsh-users@xxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- Organization: Ministry of Information, Department of Information Adjustments
- References: <20020510043355.GJ10130@xxxxxxxxxxxxx> <18763.1021023606@xxxxxxx>
* Peter Stephenson <pws@xxxxxxx> [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
>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
- 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)
Denn ein Tyrann ist nicht, wenn die Masse nicht geduldig stillhält.
- Kurt Tucholsky
Messages sorted by: