Re: umlimit and /etc/zshenv

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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.