Re: umlimit and /etc/zshenv

[Thorsten Haude <zsh@xxxxxxxxxxxxxx>]

Hi,

* Oliver Kiddle <okiddle@xxxxxxxxxxx> [02-05-10 14:35]:
>Thorsten Haude wrote:
>> 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?
I have no idea, but I will ask the developers.

>Surely it isn't calling nedit to enter the passphrase because it'd then
>have the passphrase written in clear to disc anyway.
No, the error occurs even on mails that are not encrypted or signed if
I used GPG before in the same Mutt session.

>> 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().
A legacy thing, and not even my own legacy at that.

>> - 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.
That may be to late. The crash may not be repeatable, but the core
might still give useful insights.

>> - 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.
I like being immediately notified of any problems that might arise.
Sure, I could use a logfile and some logsurfery thing.

>> - 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.
There was a discussion about this just this week. The error output
could either be done to a command line or with some dialog, both have
advantages and disadvantages.
However, the redirection cannot happen automatically since I may only
be interested in the error output.

Please understand that I don't disagree with all your suggestions, but
I want to explore the issue to find the best way of dealing with this.

Thorsten
-- 
You're not supposed to be so blind with patriotism that you can't face
reality. Wrong is wrong, no matter who does it or who says it.
	- Malcolm X