Re: umlimit and /etc/zshenv

[Thorsten Haude <zsh@thorstenhau.de>]

Hi Peter,

* Peter Stephenson <pws@csr.com> [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