Zsh Mailing List Archive
Messages sorted by:
Re: umlimit and /etc/zshenv
- X-seq: zsh-users 4956
- From: Thorsten Haude <zsh@xxxxxxxxxxxxxx>
- To: Zsh users list <zsh-users@xxxxxxxxxx>
- Subject: Re: umlimit and /etc/zshenv
- Date: Fri, 10 May 2002 23:20:27 +0200
- In-reply-to: <20020510123550.GA4281@xxxxxxxxxx>
- 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> <20020510112647.GB1124@xxxxxxxxxxxxx> <20020510123550.GA4281@xxxxxxxxxx>
* 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
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
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.
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
Messages sorted by: