Re: emacs doesn't inherit PATH from environment

[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