Re: emacs doesn't inherit PATH from environment

[Bob Proulx <bob@proulx.com>]

Larry Evans wrote:
> I understand, and after changing ; to : in ~/.emacs.d/init.common.el
> it worked; however, the point I was making is the setting of PATH
> in ~/.emacs.d/init.common.el shouldn't be needed.

I agree.  Why are doing it?  :-)

> 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.

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).

I have no idea about MS-Windows but in the Unix/GNU universe the
environment used to be simple.  In the simple days when logging in the
shell would look at it's own name and see that it started with a "-"
such as "-bash" and know that it was being communicated to by
/bin/login that it was a login shell and should source the login
environment files as a login shell should do.  That means ~/.profile
for Bourne derived shells.  (And there is no need to discuss csh
derived shells, becuase it is csh and no one should be using it
anymore.  Regardless that I know many are still using it.)

Then in the .profile a bash user would then detect that they are
running bash and if so then source the ~/.bashrc file explicitly.  If
it is not done explicitly then it is not done at all.  You are in
control.  However I can't think of a reason not to source it there.

if [ -n "$BASH_VERSION" ]; then
  . "$HOME/.bashrc"
fi

And of course a bash only user might decide to use ~/.bash_profile
instead.  If so then of course only bash reads that file and so no
test to check for running bash is needed and one can simply source the
~/.bashrc file unconditionally.  In a ~/.bash_profile file:

  . "$HOME/.bashrc"

Note that if you have a .bash_profile then it *overrides* any further
bash use of ~/.profile.  Which can frustrate you terribly if 'rvm'
decided to create it for you and you didn't realize it did that and
are trying to figure out where things went wrong.  I hate rvm for this
reason.  It makes bad assumptions and breaks things.  But I digress.

Personally I still use a ~/.profile and keep it generic.  Because that
allows me to switch around and use ksh and zsh and still get a sane
environment shared among all of them.  I put PATH only in .profile and
use ~/.bashrc for bash specific settings such as HISTCONTROL and PS1
and "shopt -s checkwinsize" and so forth.  Or by environment variables
that I might want to change from one shell invocation to the next.

This is why ~/.profile is the natural place for PATH.  So that even if
one switches shells that PATH will still be set as desired.  Since
PATH is not a shell specific item.

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.

Instead it is distribution defined behavior what happens when an xdm
such as lightdm starts.  It might do one thing or it might do another
thing but you can count on it NOT sourcing your ~/.profile!  Instead
most distributions will cause it to source a ~/.xsessionrc file.  On
my Debian system that is sourced from the /etc/X11/Xsession script by
the /bin/sh shell and therefore cannot contain any bash specific
features.  It should contain only portable shell constructs.  Setting
PATH and other variables is okay.

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.]]

That covers almost everything.  Unfortunately there is the traditional
'rsh' implemented by the current 'ssh' and shell environment.  It's
yet again a few special cases.  But not relevant here so skipping
discussing it.

I realize that all of this might be foreign concepts to an MS-Windows
user.  But that is why I wrote it.  So that it would become more
familiar and hopefully help people understand how things work.  And
perhaps people using Unix/GNU might enjoy reading it too. :-)

Bob