help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs doesn't inherit PATH from environment


From: Barry Fishman
Subject: Re: emacs doesn't inherit PATH from environment
Date: Thu, 15 Feb 2018 10:59:41 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On 2018-02-14 19:38:42 -07, Bob Proulx wrote:
> Larry Evans wrote:
>> Indeed, the setenv in ~/.emacs.d/init.common.el was deleted, but I
>> also moved the 'export PATH' from ~/.bashrc to ~/.profile. After
>> that, the Makefile worked.

Note, this is not always the case.  Commonly desktop environments just
do the /etc/profile and not any login specific shell setup like
"~/.profile".  KDE has a configuration window option to set up your
environment.

>
> Sounds good.  In my world view the best and only place to set PATH is
> in the .profile and not elsewhere.
>
> So glad to hear from you that things are working in the normal
> configuration.  That's great.
>
>> The conclusion I reached was that somehow emacs, when invoked from
>> my windows interface, apparently just runs the ~/.profile code but
>> not the ~./bashrc code and that's why emacs was not seeing the PATH
>> (because, previously it was set in ~/.bashrc).

> However, and this is a big *HOWEVER*, along came Desktop Environments
> such as GNOME, KDE, LXDE, XFCE, and others running an "xdm" or X
> Display Manager such as lightdm and others.  For some reason
> unfathomable to me they decided not to set up the originating shell as
> a login shell!  That is really a shock to me.  And one that has caused
> problems for literally decades.
>
> ...
>
> IMNHO the only sane thing to do in the ~/.xsessionrc file is to source
> the $HOME/.profile file.  They are both portable shell syntax files.
> Then put all of your environment setting in ~/.profile the same as
> always.  Otherwise one ends up with some things set one way when
> logging in with ssh and some things set another way when logging in
> with a graphical login manager.  In ~/.xsessionrc file:
>
>   . "$HOME/.profile"
>
> [[There is also the ~/.xsession script.  I used to use and recommend
> that way for years.  But I have been convinced by others that it is
> better to recommend the ~/.xsessionrc file instead.  It is less for
> people to understand using that file.]]

This does not work very well for me.  In particular, I find most of my
systems now use Wayland, so I'm not sure .xsession* files are
meaningful.  Even under X, various distributions may not reference the
~/.sessionrc file in the session startup scripts, although I used to add
it to systems without it.  Recently I just gave up.

There seems to be a conflict between the freedesktop people and the
shell maintainers on how things should be setup, and the user is left in
the crossfire.  There is now even a pam_env.so specific
"~/.pam_environment" method (with a whole new vaguely defined file
format) which sometimes works (but not always).

Personally I find myself brute forcing, and adding a zz-path.sh to
/etc/profile.d so it gets called last (and doesn't get replaced in
system updates) and just does:

if [ -f "${HOME}/.config/paths.sh" ]; then
  . "${HOME}/.config/paths.sh"
fi

And have my ~/.config/paths.sh file setup just environment information I
need for applications launched via the desktop, such as fixing PATH.

My ~/.bashrc is a link to my ~/.profile, which does the right thing
based on its own determination of if my environment has already been set
or if it is an interactive shell.

I start it with:

--8<---------------cut here---------------start------------->8---
if [ -z "$BASH" ]; then
    complete () {
      :
    }
    shopt () {
      false
    }
fi
--8<---------------cut here---------------end--------------->8---

To disable my bash specific parts when some other shell is invoked.

Emacs is still left with resolving things like where to find info
directories, but doesn't have to deal with fixing the environment.

[Rant about the freedesktop's ideas left for a more appropriate time/group]
--
Barry Fishman


reply via email to

[Prev in Thread] Current Thread [Next in Thread]