Re: ESS/Matlab Path in Cocoa Emacs

[Tim X]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Actually, AFAIK the exact same problem appears in X-windows when you
>>> start Emacs from the GUI and you set your PATH in your shell's
>>> config file.
>> One solution is to set PATH in X11' startup file, ~/.xinitrc.
>
> This is way off-topic here, obviously.
>
> And, yes, there are various workarounds (as you'd expect for a problem
> that has existed for so many years), but it's never quite that easy: the
> .xinitrc file doesn't exist, so you have to create it and know what to
> put into it, and then that presumes the display manager actually uses it
> (does it?  or does it use ~/.xsession?  or does it use neither?  or
> does it depends on the kind of session you choose at login? ...)
> IOW it's a (very longstanding) mess.
>

Yes, off topic, but a common question in this group. 

Stefan is quite correct - there are several solutions. Most of them have
their own drawbacks. 

Traditionally, the xinitrc file is only used if you start an xsession
manually or from within your login. It is not called if you start via an
X login i.e. xdm, gdm etc. It was normally only used when you used
something like startx

On many systems, modifying .Xsession (the traditional script used to
start when you use a X login) is not an option as many distributions
have set things up so that the user no longer has their own .Xsession
file. Creating an Xsession file is usually allowed, but that results in
the default system setup being ignored i.e. you need to create a full
Xsession file. (You can modify the system wide one or put a simple
script in /etc/X11/Xsession.d that sources your profile. Because xinitrc
and xsession may be run in different contexts, they may not be
equivalent, so copying xinitrc to xsession or making a symlink may not
have the desired/expected result (frequently, xinitrc just sources the
Xsession script, but it may do other things as well that may not be
compatible). 

My own personal solution use to be to change the script that runs all
the session stuff to be a login shell i.e. edit /etc/gdm/Xsession.
However, under some recent distros, such as Ubuntu, this is no longer
necessary as you have the following lines in that script

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

Note that this setup also allows you to have two sets of profiles -
normal .profile and an .xprofile. 

However, to ensure we still have fun confusing stuff, it should be noted
that by default, many distros don't have a $HOME/.profile, but instead a
$HOME/.bash_profile. I typically do a symlink from .bash_profile to
.profile as this tends to avoid some other common issues (.bash_profile
is a more recent introduction than .profile). Unfortunately, this still
leaves a few issues, especially if you don't use bash as your login
shell or if you have bash specific content in your .bash_profile/profile
(noting that the typical Xsession script is run with /bin/sh not
/bin/bash and some distributions use a light-weight sh clone rather than
just bash, which means some bash specific content could cause the script
to either fail or generate errors.

The common theme to all the solutions is that the user's
.profile/.bash_profile gets sourced by the shell that will eventually be
the shell that runs your window manager. Which solution you select
doesn't matter too much provided your environment profile script gets
sourced successfully by the Xsesion process. Personally, in this age of
package management and auto updates, I tend to avoid fixes that modify
distribution managed scripts if possible.

Traditionally, the last line of an Xsession script is to do something
like

exec window_manager

which essentially means that the shell hands over execution to the
window manager (note that this is not the same as just running the
window manager as this would run it in a sub-shell
of the Xsession shell and result in that Xsession shell hanging around.
Using exec means that the window manager takes over from the xsession
script. This is why when you log out from your window manager, you exit
your X session and why you don't see Xsession in ps output when you are
running your session. (there are some other benefits from using exec,
but not realy relevant here)

Having sourced your environment setup in the Xsession script means the
process (which will eventually become your window manager process) will
have all your environment settings. As anything that is executed as a
sub-shell will inherit those environment settings, all commands/programs
run directly or indirectly from within the window manager will run as
child processes of that parent and will be aware of those environment
settings.

Yes, this stuff is a bit of a mess. However, it is fully customizable
and you are not constrained in what you want to do. This is great for
those who love to tweak and customize their system, but a pain for those
who really don't care about that level and really just want to login and
start doing stuff. Personally, I find tweaking at the system level
boring, preferring to get on with writing code and doing other work.
However, back in the late 80s and early 90s I use to enjoy that stuff
and have enough residual knowledge I can usually resolve such issues
fairly quickly, so I'm lucky. Things may seem to still be a mess, but in
fact it is greatly improved from where we were with Linux in the mid
90s. At least it is rarely necessary to spend hours defining and
tweaking modeline entries just to get something on the screen while
wondering if all the warnings about misconfiguration damaging your
hardware were relevant to the slight modifications you were making!

Tim


-- 
tcross (at) rapttech dot com dot au