Re: environment settings

Re: environment settings

[Jörg Sommer]

Hi Stephane,

Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote:
> On Mon, Jun 16, 2008 at 02:30:46PM +0200, Marcus Franke wrote:
> [...]
>> > environment variables can be defined in the ~/.zprofile. Then
>> > they are set once, when you log in and inherited by every
>> > process. But make sure whatever process logs ou in if it's not
>> > your login shell, does read that .zprofile. You might have to do
>> > it in .profile and have .zprofile source that .profile.
>> 
>> My .zshrc just had the "EDITOR=/usr/bin/vim" line but without using
>> export :(
> [...]
>
> Which in a way makes sense though is not very useful. ~/.zshrc
> is your shell configuration file. ~/.zprofile is you session
> configuration file.
>
> Generally, in ~/.zshrc, you put stuff that affects the behavior
> of interactive shells (sets shell options, defines shell
> aliases, configure completions).
>
> In ~/.zprofile, you define what affects any process started in
> your session not necessarily only the shell processes.

And what's the meaning of .zshenv? I use it for my environment variables
like EDITOR, because my session is started by X.

Bye, Jörg.
-- 
Two types have compatible type if their types are the same.
[ANSI C, 6.2.7]

Re: environment settings

[Stephane Chazelas]

On Tue, Jun 17, 2008 at 08:33:02AM +0000, Jörg Sommer wrote:
[...]
> > Which in a way makes sense though is not very useful. ~/.zshrc
> > is your shell configuration file. ~/.zprofile is you session
> > configuration file.
> >
> > Generally, in ~/.zshrc, you put stuff that affects the behavior
> > of interactive shells (sets shell options, defines shell
> > aliases, configure completions).
> >
> > In ~/.zprofile, you define what affects any process started in
> > your session not necessarily only the shell processes.
> 
> And what's the meaning of .zshenv? I use it for my environment variables
> like EDITOR, because my session is started by X.
[...]

My understanding is that ~/.zshenv is for hacking in situations
where you can't do otherwise.

Your X login procedure should source your .zprofile or some file
that is sourced by your .zprofile if you want the same settings
in X sessions and non-X sessions. Or it should source/read
another session config file that defines env variables.

.zshenv is to fix up situations where it's not possible in my
opinion. It's like the SHELLOPTS, BASH_ENV variables with bash
or ENV with some kshs, it should be used with extreme care and
probably not permanently.

Now, that's one way to see things. You can have a different
approach where .zshenv is central, but my feeling is that it's
asking for trouble.

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 10:39:00 +0100, Stephane Chazelas wrote:
> My understanding is that ~/.zshenv is for hacking in situations
> where you can't do otherwise.

I completely disagree. ~/.zshenv is useful to define environment
variables when the first zsh shell isn't always a login shell, in
which case ~/.zprofile isn't read (e.g. when the user's main shell
is not zsh and zsh is executed from that shell, or when one uses
ssh + command; the user shouldn't be forced to use the -l flag).
This is also better than the ~/.zprofile when the user often
changes his config files and doesn't want to logout and login
again (meaning quitting the X session...).

Moreover ~/.zshenv is useful to define things that are not exported,
such as shell variables, named directories and so on, that can also
be used in non-interactive shells.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

On Tue, Jun 17, 2008 at 12:41:26PM +0200, Vincent Lefevre wrote:
> On 2008-06-17 10:39:00 +0100, Stephane Chazelas wrote:
> > My understanding is that ~/.zshenv is for hacking in situations
> > where you can't do otherwise.
> 
> I completely disagree. ~/.zshenv is useful to define environment
> variables when the first zsh shell isn't always a login shell, in
> which case ~/.zprofile isn't read (e.g. when the user's main shell
> is not zsh and zsh is executed from that shell, or when one uses
> ssh + command; the user shouldn't be forced to use the -l flag).
> This is also better than the ~/.zprofile when the user often
> changes his config files and doesn't want to logout and login
> again (meaning quitting the X session...).
> 
> Moreover ~/.zshenv is useful to define things that are not exported,
> such as shell variables, named directories and so on, that can also
> be used in non-interactive shells.
[...]

And I still think that would be a dirty hack and asking for trouble.

Changing the behavior of every zsh instance, even the instances
that run script that you've not written is very bad practice
IMO especially when you consider that the behavior is only
affected for the processes that have your euid.

So, it has its uses, but mainly for non-normal operation, when
you can't be bothered or don't have the right to do the /right
thing/.

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 13:58:34 +0100, Stephane Chazelas wrote:
> Changing the behavior of every zsh instance, even the instances
> that run script that you've not written is very bad practice
> IMO especially when you consider that the behavior is only
> affected for the processes that have your euid.

If scripts I've not written expect that [some program] is available
in $PATH, then the user may need to add directories to $PATH in his
.zshenv (e.g. because [some program] has been installed by the user
himself in his home directory).

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

On Tue, Jun 17, 2008 at 03:11:54PM +0200, Vincent Lefevre wrote:
> On 2008-06-17 13:58:34 +0100, Stephane Chazelas wrote:
> > Changing the behavior of every zsh instance, even the instances
> > that run script that you've not written is very bad practice
> > IMO especially when you consider that the behavior is only
> > affected for the processes that have your euid.
> 
> If scripts I've not written expect that [some program] is available
> in $PATH, then the user may need to add directories to $PATH in his
> .zshenv (e.g. because [some program] has been installed by the user
> himself in his home directory).
[...]

So, you have a script that expects a $PATH that is different
from the system's $PATH, and your solution is to update the
~/.zshenv for every user that is meant to run that script, and
by doing so, possibly affecting the behavior of all the other
zsh scripts that those users may run?

It seems to me that the /right thing/ would be to update the
script (or write a wrapper that sets $PATH if it's a binary file
instead of a script), or update the system's $PATH. But you can
always put it in ~/.zshenv if you can't be bothered or if you
don't have the right to update the system's $PATH.

Moreover, if you do

path+=(/some/path)
in ~/.zshenv, you'll soon end up with /some/path dupplicated.

-- 
Stéphane

Re: environment settings

[Mikael Magnusson]

2008/6/17 Stephane Chazelas <Stephane_Chazelas@yahoo.fr>:
> Moreover, if you do
>
> path+=(/some/path)
> in ~/.zshenv, you'll soon end up with /some/path dupplicated.

typeset -U path

-- 
Mikael Magnusson

Re: environment settings

[Stephane Chazelas]

On Tue, Jun 17, 2008 at 03:28:20PM +0200, Mikael Magnusson wrote:
> 2008/6/17 Stephane Chazelas <Stephane_Chazelas@yahoo.fr>:
> > Moreover, if you do
> >
> > path+=(/some/path)
> > in ~/.zshenv, you'll soon end up with /some/path dupplicated.
> 
> typeset -U path
[...]

Changing the type of $path in ~/.zshenv, that is for all zsh
shells (including script interpreters) that this user may run
seems dangerous to me.

Some scripts might expect $path[-1] to be the last component
that they added for instance.

Like:

path+=("$(some-cmd)") && print -ru2 just added $path[-1] to PATH

If something changed the type of $path behind its back, then the
above won't work correctly.

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 14:26:11 +0100, Stephane Chazelas wrote:
> So, you have a script that expects a $PATH that is different
> from the system's $PATH,

No. Please read again.

> and your solution is to update the ~/.zshenv for every user that is
> meant to run that script, and by doing so, possibly affecting the
> behavior of all the other zsh scripts that those users may run?

That's completely silly: each user controls his own ~/.zshenv.

> It seems to me that the /right thing/ would be to update the
> script

No, the script can come from a tarball or whatever.

> (or write a wrapper that sets $PATH if it's a binary file
> instead of a script),

For a global config, this can be annoying.

> or update the system's $PATH. But you can always put it in ~/.zshenv
> if you can't be bothered or if you don't have the right to update
> the system's $PATH.

Put what in ~/.zshenv? The additional bin directories (e.g. $HOME/bin)?
This is what I've said.

> Moreover, if you do
> 
> path+=(/some/path)
> in ~/.zshenv, you'll soon end up with /some/path dupplicated.

No:

# Path clean-up
path=($^path(N))

(But a duplicated path isn't fatal.)

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 15:28:20 +0200, Mikael Magnusson wrote:
> 2008/6/17 Stephane Chazelas <Stephane_Chazelas@yahoo.fr>:
> > Moreover, if you do
> >
> > path+=(/some/path)
> > in ~/.zshenv, you'll soon end up with /some/path dupplicated.
> 
> typeset -U path

It seems that I mixed up typeset -U with the N flag in my previous
mail (I also use typeset -U, but currently not yet for $path,
probably because duplicated paths never occurred here).

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 15:25:57 +0100, Stephane Chazelas wrote:
> Some scripts might expect $path[-1] to be the last component
> that they added for instance.

"typeset -U path" being a valid feature of zsh, such scripts should be
regarded as broken.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

On Tue, Jun 17, 2008 at 05:54:29PM +0200, Vincent Lefevre wrote:
> On 2008-06-17 15:25:57 +0100, Stephane Chazelas wrote:
> > Some scripts might expect $path[-1] to be the last component
> > that they added for instance.
> 
> "typeset -U path" being a valid feature of zsh, such scripts should be
> regarded as broken.
[...]

What do you mean?

Do you mean that a zsh script should expect that someone might
have put typeset -U path in its ~/.zshenv?

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 17:00:09 +0100, Stephane Chazelas wrote:
> Do you mean that a zsh script should expect that someone might
> have put typeset -U path in its ~/.zshenv?

Yes. If it doesn't like it, it can still do a typeset +U path.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

On Tue, Jun 17, 2008 at 09:50:07PM +0200, Vincent Lefevre wrote:
> On 2008-06-17 17:00:09 +0100, Stephane Chazelas wrote:
> > Do you mean that a zsh script should expect that someone might
> > have put typeset -U path in its ~/.zshenv?
> 
> Yes. If it doesn't like it, it can still do a typeset +U path.
[...]

And while we're at it, it can also do an "unfunction echo" and
"unalias echo" because someone might have redefined "echo" in
the ~/.zshenv to behave POSIXly. But first, it may want to do a
\comm"a"n\d un\function unfunction because you never know these
days what people may want to put in ~/.zshenv.

Let's be serious please. Or let's do as for csh, where one must
add the -f to the shebang line to avoid this kind of problem.

~/.zshenv can be a useful tool but it must be used with care. 

-- 
Stéphane

Re: environment settings

[Jörg Sommer]

Hi Stephane,

Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote:
> On Tue, Jun 17, 2008 at 08:33:02AM +0000, Jörg Sommer wrote:
> [...]
>> > Which in a way makes sense though is not very useful. ~/.zshrc
>> > is your shell configuration file. ~/.zprofile is you session
>> > configuration file.
>> >
>> > Generally, in ~/.zshrc, you put stuff that affects the behavior
>> > of interactive shells (sets shell options, defines shell
>> > aliases, configure completions).
>> >
>> > In ~/.zprofile, you define what affects any process started in
>> > your session not necessarily only the shell processes.
>> 
>> And what's the meaning of .zshenv? I use it for my environment variables
>> like EDITOR, because my session is started by X.
> [...]
>
> Your X login procedure should source your .zprofile

How should this work? How can a binary program or a Perl script source a
shell file?

> .zshenv is to fix up situations where it's not possible in my
> opinion. It's like the SHELLOPTS, BASH_ENV variables with bash
> or ENV with some kshs, it should be used with extreme care and
> probably not permanently.

That .zshenv is evaluated by every script is usable for me, because I set
(or update) the value of http_proxy and ftp_proxy there. Their current
value get's written to a file by a system script and I read these values
in .zshenv.

Bye, Jörg.
-- 
Es liegt in der Natur des Menschen, vernünftig zu denken und
unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte
nicht das Verstandene!

Re: environment settings

[Stephane Chazelas]

On Wed, Jun 18, 2008 at 08:49:03AM +0000, Jörg Sommer wrote:
> Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote:
> > On Tue, Jun 17, 2008 at 08:33:02AM +0000, Jörg Sommer wrote:
> > [...]
> >> > Which in a way makes sense though is not very useful. ~/.zshrc
> >> > is your shell configuration file. ~/.zprofile is you session
> >> > configuration file.
> >> >
> >> > Generally, in ~/.zshrc, you put stuff that affects the behavior
> >> > of interactive shells (sets shell options, defines shell
> >> > aliases, configure completions).
> >> >
> >> > In ~/.zprofile, you define what affects any process started in
> >> > your session not necessarily only the shell processes.
> >> 
> >> And what's the meaning of .zshenv? I use it for my environment variables
> >> like EDITOR, because my session is started by X.
> > [...]
> >
> > Your X login procedure should source your .zprofile
> 
> How should this work? How can a binary program or a Perl script source a
> shell file?
[...]

I've seen different approaches implemented. Most often, the
session startup command run's the user's shell as in
(simplified)

if user_shell =~ csh
  exec usershell -c 'source ~/.login; exec xinit'
elseif usershell =~ zsh
  exec usershell -c 'source ~/.zprofile; exec xinit'
else
  exec usershell -c '. ~/.profile; exec xinit'

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-17 21:32:29 +0100, Stephane Chazelas wrote:
> And while we're at it, it can also do an "unfunction echo" and
> "unalias echo" because someone might have redefined "echo" in
> the ~/.zshenv to behave POSIXly.

If the script uses zsh features of echo, yes. Now, in practice, if
a user writes a zsh script for himself, he knows what he has put in
his .zshenv, so that he should know what he needs to undefine in his
scripts (most often, there's nothing to do). Those who want to write
portable scripts shouldn't write zsh scripts anyway (BTW, even Debian
goes back from bash to POSIX sh). So, in short, there's no practical
problem.

> Let's be serious please. Or let's do as for csh, where one must
> add the -f to the shebang line to avoid this kind of problem.

Well, concerning csh, the -f is necessary just because users do nasty
things in their .cshrc (but csh is also at fault by not have something
like .cshenv where users can put *minimal* things). Anyway csh is
incompatible with everything else, has bugs and is no longer standard.
One should not write csh scripts any longer.

> ~/.zshenv can be a useful tool but it must be used with care. 

Yes, it must be used with care, but this is also true for other
config files.

Also, bash is really annoying by not sourcing some rc file:

brocoli:~> which tps
/home/vlefevre/bin/tps

(I install my own utilities, written by myself, in my home directory.)

brocoli:~> ssh -t doublejack tps
Connected to doublejack (from 140.77.14.28)
DISPLAY: localhost:11.0
bash: tps: command not found
Connection to doublejack closed.

Fortunately this has been fixed in Debian.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

So, to sum up.

~user/.zshrc is the interactive shell customisation file of the user
~user/.zprofile is the login session customisation file of the user
~user/.zshenv can be used to set environment for every process
run by the corresponding user through zsh.

Most of the processes a user every runs are run during his login
session. Exceptions one can think of are:

- cron jobs: cron(8) generally doesn't run the user's shell but
  sh to parse the job command line, so .zshenv won't be sourced
  unless the cron job is a zsh script.
- ssh/rsh cmd. sshd/rshd does use the user's shell (which can be
  a pain), so .zshenv will be sourced if the user's login shell
  is zsh
- rexec, no shell involved.
- ~/public_html/xxx.cgi: no shell involved.
- ~/.forward: depends on the MTA, I don't think the user's shell
  is involved.

Basically, there's nothing for "a file that should set env
variable for every process run by this given user".

But in all the cases above, the user can explicitely call a "sh"
that sources a file that does the "exports".

-- 
Stéphane

Re: environment settings

[Bart Schaefer]

On Jun 18, 12:52pm, Stephane Chazelas wrote:
}
} Most of the processes a user every runs are run during his login
} session.
}
} Basically, there's nothing for "a file that should set env
} variable for every process run by this given user".

The definition of a "login session" has unfortunately become very
uncertain.  The Gnome desktop via GDM on Ubuntu, for example, does
not perform "login session"-type initialization (or at least, does
not do so in a way specific to the user's shell from /etc/passwd).
The default gnome-terminal configuration also does not create login
shells when opening new windows.  Without some more-than-trivial
knowledge of Gnome configuration, there is no way for a user to
accomplish the things that you attribute to a single login session.

} - ~/.forward: depends on the MTA, I don't think the user's shell
}   is involved.

It depends on the program invoked (procmail derives $SHELL from
/etc/passwd -- users are often advised to add SHELL=/bin/sh early
in their .procmailrc unless they know exactly what they are doing).
Also, there are ways other than the .forward that filter programs,
etc. can be invoked from an MTA.

} But in all the cases above, the user can explicitely call a "sh"
} that sources a file that does the "exports".

Even granting that this is true, why solve the same problem again
every time a new situation comes up?

For example purposes, here's part of what I do in .zshenv:

----
if [[ -O $HOME ]]
then 
  # Use version-controlled configuration library if available
  [[ -d $HOME/.zsh ]] && ZDOTDIR=$HOME/.zsh
else
  # Not me, or not my home directory, don't read the startup files
  setopt NO_RCS
  return 0
fi
PATH=${ZSH_ENVPATH:-$PATH}
export ZSH_ENVPATH=$PATH
----

This is followed by some miscellaneous stuff to delete stupid settings
that misguided Linux packagers have at various times placed in the
/etc/zshenv file, and set $fpath in case $0 indicates I'm running zsh
from a non-standard location (like out of my development sandbox).  The
ZSH_ENVPATH setting assures that I can always reset $PATH to the system
default before modifying it.

Re: environment settings

[Wayne Davison]

On Tue, Jun 17, 2008 at 08:33:02AM +0000, J?rg Sommer wrote:
> And what's the meaning of .zshenv? I use it for my environment variables
> like EDITOR, because my session is started by X.

I've been bitten by unwanted side effects when using .zshenv to set
environment variables, so the following lines are pretty much the
entirety of my .zshenv file these days:

if [[ $SHLVL == 1 && ! -o LOGIN ]]; then
    source ~/.zprofile
fi

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.
A similar problem arises for any zsh script that you want to run inside
a customized environment -- the .zshenv values always override any
settings you made prior to starting the script.

..wayne..

Re: environment settings

[Vincent Lefevre]

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@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

On Sat, Jun 21, 2008 at 01:36:59PM +0200, Vincent Lefevre wrote:
> 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).
[...]

I think this is what Wayne had in mind:

$ echo A=x >> ~/.zshenv
$ env -i A=y SHELL=zsh strace -vfe execve =gdb --args env
execve("/usr/bin/gdb", ["/usr/bin/gdb", "--args", "env"], ["A=y", "SHELL=zsh"]) = 0
[...]
(gdb) run
Starting program: /home/chazelas/env
[...]
[pid  9335] execve("/bin/zsh", ["zsh", "-c", "exec /home/chazelas/env "], ["A=y", "SHELL=zsh", "LINES=52", "COLUMNS=144"]) = 0
[pid  9335] execve("/home/chazelas/env", ["/home/chazelas/env"], ["A=x", "SHELL=zsh", "LINES=52", "COLUMNS=144", "HOME=/home/chazelas", "LOGNAME=chazelas", "SHLVL=0", "PWD=/home/chazelas", "OLDPWD=/home/chazelas", "_=/home/chazelas/env"]) = 0
A=x
[...]

The program to debug (here env) is run through $SHELL which
sources ~/.zshenv which overrides the setting of the A variable.
(PATH in Wayne's case).

It's not gdb's fault and there's nothing it can do about it.

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-21 13:30:50 +0100, Stephane Chazelas wrote:
> The program to debug (here env) is run through $SHELL which
> sources ~/.zshenv which overrides the setting of the A variable.
> (PATH in Wayne's case).
> 
> It's not gdb's fault and there's nothing it can do about it.

OK, it is explained in the manual that argument building is done by
gdb, using $SHELL:

The _arguments._
     Specify the arguments to give your program as the arguments of the
     `run' command.  If a shell is available on your target, the shell
     is used to pass the arguments, so that you may use normal
     conventions (such as wildcard expansion or variable substitution)
     in describing the arguments.  In Unix systems, you can control
     which shell is used with the `SHELL' environment variable.  *Note
     Your Program's Arguments: Arguments.

So, this is even worse. For instance, if the user changes the way
arguments are built (e.g. I use "setopt EXTENDED_GLOB" in my .zshrc),
such options should actually be in the .zshenv to get the same
behavior!

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Stephane Chazelas]

On Sun, Jun 22, 2008 at 10:41:52AM +0200, Vincent Lefevre wrote:
> On 2008-06-21 13:30:50 +0100, Stephane Chazelas wrote:
> > The program to debug (here env) is run through $SHELL which
> > sources ~/.zshenv which overrides the setting of the A variable.
> > (PATH in Wayne's case).
> > 
> > It's not gdb's fault and there's nothing it can do about it.
> 
> OK, it is explained in the manual that argument building is done by
> gdb, using $SHELL:
> 
> The _arguments._
>      Specify the arguments to give your program as the arguments of the
>      `run' command.  If a shell is available on your target, the shell
>      is used to pass the arguments, so that you may use normal
>      conventions (such as wildcard expansion or variable substitution)
>      in describing the arguments.  In Unix systems, you can control
>      which shell is used with the `SHELL' environment variable.  *Note
>      Your Program's Arguments: Arguments.
> 
> So, this is even worse. For instance, if the user changes the way
> arguments are built (e.g. I use "setopt EXTENDED_GLOB" in my .zshrc),
> such options should actually be in the .zshenv to get the same
> behavior!
[...]

Note that $SHELL is called for that purpose in a number of
places such as vi's :!, ftp's !, ssh host 'cmd line'... not only
gdb.

It's true it would be nice to be able to distinguish between zsh
instances that are meant to be user shells that is that are
meant to parse command lines given by the user and instances
that are meant to run canonical zsh code where the user is not
meant to alter the zsh behavior (as in zsh scripts, zsh -c ...) 

csh solves that with the -f option without which every csh
instance is sourcing .cshrc (so csh scripts have #! /bin/csh
-f).

With zsh, you could solve that by having $SHELL be
/path/to/user-zsh, user-zsh being a link to zsh and ~/.zshenv
having something like:

[[ $0 != (*/|)user-zsh || -o interactive ]] ||
  . "${ZDOTDIR:-$HOME}/.zshrc"

(not tested but you get the idea).

-- 
Stéphane

Re: environment settings

[Vincent Lefevre]

On 2008-06-23 16:24:31 +0100, Stephane Chazelas wrote:
> Note that $SHELL is called for that purpose in a number of
> places such as vi's :!, ftp's !,

In those cases, sourcing the .zshenv doesn't hurt. On the contrary,
it allows to define some aliases or whatever the user wishes.

> ssh host 'cmd line'... not only gdb.

ssh runs the user's default login shell on the remote host, which can
be different from $SHELL. And this was the problem I was mentioning
with bash: there's no way to set up some environment variables. So,
with bash, "ssh -t host some_program" won't work if some_program is
in the user's $HOME/bin directory, even though the user always has
this directory in his $PATH.

> It's true it would be nice to be able to distinguish between zsh
> instances that are meant to be user shells that is that are
> meant to parse command lines given by the user and instances
> that are meant to run canonical zsh code where the user is not
> meant to alter the zsh behavior (as in zsh scripts, zsh -c ...) 

Yes, but I doubt this would solve all the problems. When I use
"zsh -c", I want .zshenv to be sourced (the reason is that I
sometimes do "ssh [-t] host zsh -c ..." and the .zshenv is the
*only* way to set up environment variables -- but I could also
source my .zshenv at the beginning of the command string).

> csh solves that with the -f option without which every csh
> instance is sourcing .cshrc (so csh scripts have #! /bin/csh
> -f).

But this solution needs to hardcode the csh path in the script.
Something like "#!/usr/bin/env csh -f" doesn't work everywhere.

> With zsh, you could solve that by having $SHELL be
> /path/to/user-zsh, user-zsh being a link to zsh and ~/.zshenv
> having something like:
> 
> [[ $0 != (*/|)user-zsh || -o interactive ]] ||
>   . "${ZDOTDIR:-$HOME}/.zshrc"
> 
> (not tested but you get the idea).

Yes, nice idea.

Concerning gdb (which is an exception), I could write a wrapper that
sets some environment variable, which could be tested in the .zshenv
to do what I want exactly.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

Re: environment settings

[Bart Schaefer]

On Jun 23,  4:24pm, Stephane Chazelas wrote:
}
} It's true it would be nice to be able to distinguish between zsh
} instances that are meant to be user shells that is that are
} meant to parse command lines given by the user and instances
} that are meant to run canonical zsh code where the user is not
} meant to alter the zsh behavior (as in zsh scripts, zsh -c ...) 
} 
} With zsh, you could solve that by having $SHELL be /path/to/user-zsh

Unfortunately I think you at least have to turn this inside-out, because
/etc/passwd usually is restricted to values that are in /etc/shells.

So something like this in .zshenv:

if [[ $0 != (*/|)user-zsh && -o interactive ]]; then
  export SHELL=~/bin/user-zsh
  # ... etc. ...
fi

But that's not going to address Vincent's complaint that shells started
for globbing by e.g. GDB should pick up settings like extended_glob.
Even SHLVL isn't always accurate; what you'd really need to do is look
up the parent process and decide based on that.

Re: environment settings

[Stephane Chazelas]

On Mon, Jun 23, 2008 at 09:20:11AM -0700, Bart Schaefer wrote:
> On Jun 23,  4:24pm, Stephane Chazelas wrote:
> }
> } It's true it would be nice to be able to distinguish between zsh
> } instances that are meant to be user shells that is that are
> } meant to parse command lines given by the user and instances
> } that are meant to run canonical zsh code where the user is not
> } meant to alter the zsh behavior (as in zsh scripts, zsh -c ...) 
> } 
> } With zsh, you could solve that by having $SHELL be /path/to/user-zsh
> 
> Unfortunately I think you at least have to turn this inside-out, because
> /etc/passwd usually is restricted to values that are in /etc/shells.
> 
> So something like this in .zshenv:
> 
> if [[ $0 != (*/|)user-zsh && -o interactive ]]; then
>   export SHELL=~/bin/user-zsh
>   # ... etc. ...
> fi
> 
> But that's not going to address Vincent's complaint that shells started
> for globbing by e.g. GDB should pick up settings like extended_glob.
> Even SHLVL isn't always accurate; what you'd really need to do is look
> up the parent process and decide based on that.

Then you can set $SHELL to user-zsh in .zprofile and use the
same trick as I was suggesting (that is source .zshrc in .zshenv
if $0 is user-zsh). Won't work for ssh though.

That's the kind of trick you use when you want to use zsh on
systems where zsh is not installed system-wide or where you're
not allowed to change your login shell (
# ~/.profile simplified
SHELL=~/bin/user-zsh
export SHELL
exec "$SHELL"
)


-- 
Stéphane