Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: environment settings
- X-seq: zsh-workers 25227
- From: Vincent Lefevre <vincent@xxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: environment settings
- Date: Sat, 21 Jun 2008 13:36:59 +0200
- In-reply-to: <20080621062649.GA28022@xxxxxxxxx>
- Mail-followup-to: zsh-workers@xxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20080616074651.GB26165@marcus> <20080616080556.GA5091@xxxxxxxxxxxxxxx> <20080616123045.GC26165@marcus> <20080616124450.GC5091@xxxxxxxxxxxxxxx> <slrng5etlu.mft.joerg@xxxxxxxxxxxx> <20080621062649.GA28022@xxxxxxxxx>
On 2008-06-20 23:26:49 -0700, Wayne Davison wrote:
> The problem I ran into with setting variables in .zshenv is that they
> can override settings you want to affect a program and/or script when
> you don't expect it. For instance, if you need to debug a C program
> that is run inside a script with a custom PATH. You setup the custom
> PATH and run the C program under gdb, and discover that your PATH isn't
> set right for the C program. This is because gdb starts the program
> under an instance of $SHELL, which will source .zshenv, and if you're
> setting PATH inside, that blasts the PATH setting you're expecting.
I'd say that this is a bug of gdb if it doesn't restore the intended
$PATH (a bit like what libtool does, AFAIK). BTW, isn't $SHELL for
the user?
Note this I really want zsh subshells I start to be run with a
cleaned-up environment (this is a *user* choice).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author