Re: Bug#198887: emacs21: envvars not being inherited everywhere
Arnaud Vandyck writes:
> I put "export CVS_RSH=ssh" into the file ~/.foo. Then I log in
> via kdm/gdm/xdm and start a shell. Typing "echo $CVS_RSH" into
> that shell gives me ssh. Good. I invoke Emacs from that shell.
> Typing M-: (getenv "CVS_RSH") RET into that Emacs gives me ssh.
> Good. I invoke Emacs from the menu. Now typing M-: (getenv
> "CVS_RSH") RET gives me nil. Bad.
^^^
No, this is good, this is how UNIX envvars were designed to work.
The real problem is with kdm/gdm/xdm logins, in that a proper
login environment is not established, and even worse, it is
nowhere documented that this is the case, and how to workaround
it.
Here is my workaround, is goes into my ~/.xsession file, which is
a #!/bin/sh script,
# Source profiles only if not yet done so.
if test "${ENV:-XXXX}" != "${env:-YYYY}" ; then
test -f /etc/profile && . /etc/profile
test -f ${HOME}/.profile && . ${HOME}/.profile
fi
which works with xdm, since it sources/execs ~/.xsession, YMMV for
kdm/gdm. Note that all of my envvars are defined in ~/.profile,
including "ENV" and "env", which are both set to ~/.sh_env (my
~/.bashrc just sources $ENV if it exists, and "env" is a
convenience variable to avoid using the SHIFT key).
I'll guess that your xterm (or whatever program that the shell
runs under) is started with the -ls (login shell option), this is
an incomplete solution to not having the proper login environment
established. Such usage usually indicates lack of understanding
of how envvars are defined and inherited.
--
Jeff Sheinberg
Reply to: