emacs doesn't inherit PATH from environment

[Larry Evans]

When executing a Makefile or invoking eshell, the PATH is not the same
as when running from a terminal window. Even when I modify the
PATH in the emacs initialization code in ~/emacs.d/init.common.el,
the executables in the PATH are *not* found.

For example, in a terminal:

evansl@lje-OptiPlex-9020:~$ echo $PATH
/home/evansl/anaconda3/bin:/home/evansl/miniconda3/bin:/home/evansl/.nvm/versions/node/v7.7.1/bin:/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
evansl@lje-OptiPlex-9020:~$ which pdf2txt.py
/home/evansl/anaconda3/bin/pdf2txt.py
evansl@lje-OptiPlex-9020:~$

However, in emacs eshell with the PATH set in ~/emacs.d/init.common.el:

Welcome to the Emacs shell

~/.emacs.d $ echo $PATH
/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
~/.emacs.d $ which pdf2txt.py
which: no pdf2txt.py in
(/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin)
~/.emacs.d $ ls -ld /home/evansl/anaconda3/bin/pdf2txt.py
-rwxrwxr-x 1 evansl evansl 3436 2018-02-12 06:18
/home/evansl/anaconda3/bin/pdf2txt.py
~/.emacs.d $

My emacs version and OS:

evansl@lje-OptiPlex-9020:~$ emacs --version
GNU Emacs 24.5.1
Copyright (C) 2015 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
evansl@lje-OptiPlex-9020:~$ uname -a
Linux lje-OptiPlex-9020 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19
11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
evansl@lje-OptiPlex-9020:~$

How can I get emacs to find pdf2txt.py?

TIA.

-regards,
Larry

[Emanuel Berg]

Larry Evans wrote:

> When executing a Makefile or invoking eshell,
> the PATH is not the same as when running from
> a terminal window. Even when I modify the
> PATH in the emacs initialization code in
> ~/emacs.d/init.common.el, the executables in
> the PATH are *not* found.

Where and how do you set PATH?

Shell stuff that I want available from Emacs
I have to set in a special file for zsh, which
is

~/.zshenv

If I put the same thing in plain .zshrc or
a file loaded from there, it doesn't work!

I never understood why because the Emacs
instance is run from a zsh shell, but for some
reason Emacs cannot see zsh stuff that aren't
defined in that special file, even when (as
said) executed from a point which HAS access to
it all!

My experience with this has only been
*functions*, not environmentals, but it is
worth a shot.

Also, you can use this to check the value prior
to starting the shell and Makefile compilation
session:

(getenv "PATH")

Is it correct?

--
underground experts united
http://user.it.uu.se/~embe8573

[Larry Evans]

Thanks for your feedback, Emanuel.

Yes, PATH is correct; however, I did use a different method to show its
value:

Here's my Makefile:

--{--cut here--
which:
echo "PATH=$(PATH)"
ls -ld /home/evansl/anaconda3/bin/pdf2txt.py
which pdf2txt.py
--}--cut here--
and heres the make invocation from within emacs:
--{--cut here--
-*- mode: compilation; default-directory:
"~/prog_dev/python/pdfminer/pdfminer/" -*-
Compilation started at Tue Feb 13 17:47:05

echo $PATH ; make -k which

/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

echo
"PATH=/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
PATH=/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
ls -ld /home/evansl/anaconda3/bin/pdf2txt.py
-rwxrwxr-x 1 evansl evansl 3436 Feb 12 06:18
/home/evansl/anaconda3/bin/pdf2txt.py
which pdf2txt.py
Makefile:29: recipe for target 'which' failed
make: *** [which] Error 1

Compilation exited abnormally with code 2 at Tue Feb 13 17:47:05
--}--cut here--
and before doing all that, I created a ~/.bashenv using the
name pattern you gave in your post (~/.$(SHELL)env):

--{--cut here--
evansl@lje-OptiPlex-9020:~$ pwd
/home/evansl
evansl@lje-OptiPlex-9020:~$ cat .bashenv
#let emacs know the environment
. .bashrc
evansl@lje-OptiPlex-9020:~$ tail .bashrc
fi

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

# added by Miniconda3 installer
export PATH="/home/evansl/miniconda3/bin:$PATH"

# added by Anaconda3 installer
export PATH="/home/evansl/anaconda3/bin:$PATH"
evansl@lje-OptiPlex-9020:~$
--}--cut here--

So, I still can't figure how to get emacs to find pdf2txt.py in
home/evansl/anaconda3/bin/ by setting PATH somehow.

-regards,
Larry

[Emanuel Berg]

Larry Evans wrote:

> So, I still can't figure how to get emacs to
> find pdf2txt.py in home/evansl/anaconda3/bin/
> by setting PATH somehow.

Try to make the example as small as possible.
Like a shell script or/and a Makefile that
echoes PATH and then execute the script.

Also try place a dummy executable in the same
dir and execute that. Does that work?

[Larry Evans]

On 02/13/2018 06:11 PM, Emanuel Berg wrote:
> Larry Evans wrote:
>
>> So, I still can't figure how to get emacs to
>> find pdf2txt.py in home/evansl/anaconda3/bin/
>> by setting PATH somehow.
>
> Try to make the example as small as possible.

The one shown previously is pretty small!

> Like a shell script or/and a Makefile that
> echoes PATH and then execute the script.
>
> Also try place a dummy executable in the same
> dir and execute that. Does that work?
>

OK, but this Makefile is the same as the previous one
except for the echo of $PATH before the make and
the additional print and the execution of the
dummy_executable.sh script:

--{--cut here--
which:
echo "PATH=$(PATH)"
ls -ld /home/evansl/anaconda3/bin/pdf2txt.py

cat dummy_executable.sh
./dummy_executable.sh

which pdf2txt.py
--}--cut here--

Here's the result of invoking make from emacs:

--{--cut here--
-*- mode: compilation; default-directory:
"~/prog_dev/python/pdfminer/pdfminer/" -*-

Compilation started at Tue Feb 13 18:47:20

make -k which

echo
"PATH=/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
PATH=/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
ls -ld /home/evansl/anaconda3/bin/pdf2txt.py
-rwxrwxr-x 1 evansl evansl 3436 Feb 12 06:18
/home/evansl/anaconda3/bin/pdf2txt.py

cat dummy_executable.sh
#!/bin/bash
echo $PATH
./dummy_executable.sh

/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

which pdf2txt.py
Makefile:29: recipe for target 'which' failed
make: *** [which] Error 1

Compilation exited abnormally with code 2 at Tue Feb 13 18:47:20

--}--cut here--

Does that help?

-regards,
Larry

[Emanuel Berg]

Larry Evans wrote:

> "PATH=/home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"

Aha! The semi-colon should be colons!

[Emanuel Berg]

Larry Evans wrote:

> The one shown previously is pretty small!

FTR I was thinking:

all:
ls # test if /bin/ls is in PATH

then cd to dir and

$ make

[Glenn Morris]

Larry Evans wrote:

> However, in emacs eshell with the PATH set in ~/emacs.d/init.common.el:
>
> Welcome to the Emacs shell
>
> ~/.emacs.d $ echo $PATH

> /home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Incorrect use of ";" rather than ":" to separate elements at the start of PATH.

[Robert Thorpe]

Emanuel Berg <moa...@zoho.com> writes:

> Shell stuff that I want available from Emacs
> I have to set in a special file for zsh, which
> is
>
> ~/.zshenv
>
> If I put the same thing in plain .zshrc or
> a file loaded from there, it doesn't work!
>
> I never understood why because the Emacs
> instance is run from a zsh shell, but for some
> reason Emacs cannot see zsh stuff that aren't
> defined in that special file, even when (as
> said) executed from a point which HAS access to
> it all!

I suspect that this is due to the differences between various shells.
There are login shells and non login shells. There are interactive
shells and non-interactive shells. These behave in different ways.
They load different variables and they reveal different things to other
programs and shells executed within them.

Using shells from within Emacs can cause problems with these defaults
because it can trick the shell into thinking that the use is
non-interactive.

Have a look at th Zsh documentation, it will probably explain some
obscure caveats about using .zshrc.

BR,
Robert Thorpe

[Emanuel Berg]

Glenn Morris wrote:

> Incorrect use of ";" rather than ":" to
> separate elements at the start of PATH.

Check you PATH every day!

(prog1
(insert "\n")
(mapc
(lambda (p) (insert p "\n"))
(split-string (getenv "PATH") ":") ))

[Emanuel Berg]

Robert Thorpe wrote:

> Have a look at th Zsh documentation, it will
> probably explain some obscure caveats about
> using .zshrc.

Unfortunately, reading zsh documentation is
like a full-time job, with the exception you
actually have to *do* it!

But Emacs + zsh isn't such an uncommon
combination, so perhaps someone reading this
still knows...

[Robert Thorpe]

Like Emanuel I'm having some trouble understanding your example.

Why are you talking about Makefiles here? Is the problem the setting of
the path variable within Emacs or the setting within Make?

Is the problem that Make works differently when executed from inside
Emacs than when executed outside Emacs?

As Emanuel wrote earlier you can find the setting in Emacs by using:

(getenv "PATH")

BR,
Robert Thorpe

[Larry Evans]

On 02/13/2018 07:27 PM, Glenn Morris wrote:
> Larry Evans wrote:
>
>> However, in emacs eshell with the PATH set in ~/emacs.d/init.common.el:
>>
>> Welcome to the Emacs shell
>>
>> ~/.emacs.d $ echo $PATH
>> /home/evansl/anaconda3/bin;/home/evansl/miniconda3/bin;/home/evansl/dwnlds/depot_tools/depot_tools:/home/evansl/dwnlds/gsrc.top/install/bin:/home/evansl/bin:/opt/OpenPrinting-Gutenprint/sbin:/opt/OpenPrinting-Gutenprint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
>

> Incorrect use of ";" rather than ":" to separate elements at the start of PATH.
>
>

AH! Correct. After change to : all worked as expected:

--{--cut here--
-*- mode: compilation; default-directory:
"~/prog_dev/python/pdfminer/pdfminer/" -*-

Compilation started at Tue Feb 13 20:22:30

make -k which
tail ~/.emacs.d/init.common.el
(transient-mark-mode 1)
))

(setenv "PATH"
(concat
"/home/evansl/anaconda3/bin" ":"
"/home/evansl/miniconda3/bin" ":"
(getenv "PATH")
)
)
which pdf2txt.py
/home/evansl/anaconda3/bin/pdf2txt.py

Compilation finished at Tue Feb 13 20:22:30

--}--cut here--
Thanks to everybody for the help and especially to those
who caught the typo ;)

-regards,
Larry

[Larry Evans]

On 02/13/2018 07:45 PM, Robert Thorpe wrote:
>
> Like Emanuel I'm having some trouble understanding your example.
>
> Why are you talking about Makefiles here? Is the problem the setting of
> the path variable within Emacs or the setting within Make?
>

Within Make

> Is the problem that Make works differently when executed from inside
> Emacs than when executed outside Emacs?

I've not tried Make from outside emacs.

> As Emanuel wrote earlier you can find the setting in Emacs by using:
>
> (getenv "PATH")
>

Since I want the PATH in the Makefile, that's not relevant.
Sorry I should have been clearer. I assumed that the PATH
in make would be the sane in emacs.
> BR,
> Robert Thorpe
>
>
>

[Larry Evans]

But why must I prepend the missing paths with that
(setenv "PATH"...) in my ~/.emacs.d/init.common.el?
After all, according to:

The value of environment variable “PATH” is used by emacs when you are
running a shell in emacs, similar to when you are using a shell in
a terminal.

from here:

https://www.emacswiki.org/emacs/ExecPath

that should be done automatically.

I think the answer is that I usually invoke emacs
from a pulldown menu in my window system, and I'm
guessing that doesn't use my bash environmnent.
However, when, in my ~/.profile, the PATH is exported,
then *that* PATH shows up in emacs; so, I'm guessing
the windowing system uses sh instead of bash and
therefore the PATH is taken from sh instead of bash.

-regards,
Larry

[Bastian Beischer]

Hello Emanuel,

On Tue, Feb 13, 2018 at 8:12 PM, Emanuel Berg <moa...@zoho.com> wrote:
>
> Larry Evans wrote:
>
> > When executing a Makefile or invoking eshell,
> > the PATH is not the same as when running from
> > a terminal window. Even when I modify the
> > PATH in the emacs initialization code in
> > ~/emacs.d/init.common.el, the executables in
> > the PATH are *not* found.
>
> Where and how do you set PATH?
>
> Shell stuff that I want available from Emacs
> I have to set in a special file for zsh, which
> is
>
> ~/.zshenv
>
> If I put the same thing in plain .zshrc or
> a file loaded from there, it doesn't work!
>
> I never understood why because the Emacs
> instance is run from a zsh shell, but for some
> reason Emacs cannot see zsh stuff that aren't
> defined in that special file, even when (as
> said) executed from a point which HAS access to
> it all!
>
> My experience with this has only been
> *functions*, not environmentals, but it is
> worth a shot.

There is a key difference between functions and variables. In zsh
functions are not exported to subshells (except for (...) subshells),
unlike exported variables. In bash you can mark functions with
'typeset -fx' to propagate them to subshells, but I think with zsh
that's not possible and you need to redefine them in a shell startup
file which is read when the subshell is spawned. Typically these
subshells are 'interactive non-login' shells so possible places are
~/.zshrc and ~/.zshenv, but not ~/.zprofile. ~/.zshenv is always read,
also in non-interactive scripts, which is why I don't like to use it.
It is also possible to place the code for the function in a separate
file in $FPATH and use autoloads, but even that does not work without
the autoload line in ~/.zshrc or ~/.zshenv for subshells.

For variables none of this should matter: As long as the variable is
exported it should be visible in the subshell. However, I don't think
'eshell' is a real shell, so that may be a different story.

[Robert Thorpe]

Larry Evans <cpplj...@suddenlink.net> writes:

> But why must I prepend the missing paths with that
> (setenv "PATH"...) in my ~/.emacs.d/init.common.el?
> After all, according to:
>
> The value of environment variable “PATH” is used by emacs when you are
> running a shell in emacs, similar to when you are using a shell in
> a terminal.
>
> from here:
>
> https://www.emacswiki.org/emacs/ExecPath
>
> that should be done automatically.
>
> I think the answer is that I usually invoke emacs
> from a pulldown menu in my window system, and I'm
> guessing that doesn't use my bash environmnent.
> However, when, in my ~/.profile, the PATH is exported,
> then *that* PATH shows up in emacs; so, I'm guessing
> the windowing system uses sh instead of bash and
> therefore the PATH is taken from sh instead of bash.

I'm not sure I understand what your saying here.

The point that Glenn Morris made is that the separator for path elements
is ":" on Unix-like systems.

It should be possible to fix $PATH anywhere. It should if you change
the semi-colons to colons in the original definition or within Emacs.
Of course, if you only do it in Emacs then only tools called from Emacs
will see the change.

BR,
Robert Thorpe

[Larry Evans]

On 02/14/2018 05:18 PM, Robert Thorpe wrote:
> Larry Evans <cpplj...@suddenlink.net> writes:
>
>> But why must I prepend the missing paths with that
>> (setenv "PATH"...) in my ~/.emacs.d/init.common.el?
>> After all, according to:
>>
>> The value of environment variable “PATH” is used by emacs when you are
>> running a shell in emacs, similar to when you are using a shell in
>> a terminal.
>>
>> from here:
>>
>> https://www.emacswiki.org/emacs/ExecPath
>>
>> that should be done automatically.
>>
>> I think the answer is that I usually invoke emacs
>> from a pulldown menu in my window system, and I'm
>> guessing that doesn't use my bash environmnent.
>> However, when, in my ~/.profile, the PATH is exported,
>> then *that* PATH shows up in emacs; so, I'm guessing
>> the windowing system uses sh instead of bash and
>> therefore the PATH is taken from sh instead of bash.
>
> I'm not sure I understand what your saying here
>

> The point that Glenn Morris made is that the separator for path elements
> is ":" on Unix-like systems.

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

[Bob Proulx]

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

[Barry Fishman]

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

[Bob Proulx]

Barry Fishman wrote:

> Bob Proulx wrote:
> > 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.
>

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

Ah, yes, Wayland. Yet another case where everything is different.

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

Unfortunately it seems every distro tried to do things their own way.

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

I would say there seems to be a conflict between the freedesktop
people and, well, everyone else. :-(

The shell has had a stable API for decades. I don't see there being
any conflict between the shell maintainers and anyone. They certainly
are not making any changes in the last decade or so about it. We
could be using the v7 Bourne shell here and nothing either of us has
said would have substantially changed. (I don't consider the .bashrc
part to be conceptually a problem with what we are discussing so far.
Although I realize it adds another layer to it. Since for zsh users
it would be .zshrc; or ENV=$HOME/.kshrc, or .cshrc, and so forth.)

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

That isn't supported on the systems I use, for example. And I don't
think it is a good idea either. I think we should be using the
standard interfaces that already exist and not creating new and
different badly supported ways of doing the same thing differently.

> 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

I know you are using profile.d to react to what is happening around
you. But I have a comment about use of profile.d in general.

When packages put files in /etc/profile.d/foo.sh then I know that they
do not understand that this makes it impossible to install something
and have it immediately available. Because that env file won't be
sourced and available until the user logs out and then logs back in
again. For most people today if you tell them to log out and log back
in again they might as well be rebooting their system. It's basically
the same for them.

Instead packages should install in such a way that whatever they are
installing is immediately usable by the logged in user without needing
to log out and back in again. I feel /etc/profile.d/foo.sh is a
*HUGE* step backwards in usability.

> 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 think what you have done is a great workaround for you. However I
still see it as a workaround and not a real solution. And even
without looking at the details of what you needed to do to accomplish
it I think 80% of users will have glazed eyes and be lost by it.

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

I was wrong. It's not 80% it's 99.44% of users will not want this
much complexity in their lives. :-) :-) [/me laughs]

In summary I think the root cause of most of these environment
problems is inconsistency. Most OS's are inconsistent with each
other. And even within a single OS it is very inconsistent what
should be done depending upon what you are using. /bin/login, ssh,
X, Wayland, and so forth, are all different. They all use the shell
and the shell is therefore by definition consistent with itself. But
those all set up the shell in different ways. I think that is problem.

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

My biggest rant there has to do with info files not always being
installed due to other long standing philosophical debates that I will
leave elsewhere. But then if they are not installed the info command
line utility falls back to displaying man pages. That makes people
dislike info even more. :-(

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

I'm right there with you! We should be having a beer in the pub and
working out the problem. :-)

Bob

[Emanuel Berg]

Larry Evans wrote:

> But why must I prepend the missing paths with
> that (setenv "PATH"...) in my
> ~/.emacs.d/init.common.el?

Yeah, don't do that.

A computer system has a hierarchy to everything
and the PATH is set in a sphere below the
sphere that runs Emacs and other programs.

So set in in one of your shell's init
files instead.

[Emanuel Berg]

Larry Evans wrote:

> I understand, and after changing ; to : in
> ~/.emacs.d/init.common.el it worked; however,

This reminds me of a story when I went to
Computer School (CS). A couple of hundred
meters from the school building was an
industrial pit, and down there one could see
flames every hour of the day - it was part of
the commune's system for disposing of garbage.
Anyway one time me and a group of students,
12 in total, went to see the professor who had
walked to this place. When we arrived, he
asked, "what is it that you want to hear from
my mouth, that you cannot hear just as well
from your own?" To this, all students started
to talk at once so not a single word was heard.
The professor then said, "you are too many
heads for one body", and pushed 11 students
into the flames.

[Emanuel Berg]

Bastian Beischer wrote:

> There is a key [...]

OK, excellent!

Thanks a lot.