From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: ESS/Matlab Path in Cocoa Emacs Date: Wed, 29 Dec 2010 11:08:22 +1100 Organization: Unlimited download news at news.astraweb.com Message-ID: <87tyhxwidl.fsf@puma.rapttech.com.au> References: <81FF9CD0-F958-41C4-B8C9-BC9C4BD653AD@gmail.com> <9E0C344F-F051-4E0B-9D92-BD40CFD05610@Web.DE> <5F78B08B-BB4A-4B10-BE7C-955C786BA309@gmail.com> <3E1015A4-2D4D-4FCA-851B-D80AE0FB11BB@Web.DE> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1293583246 21724 80.91.229.12 (29 Dec 2010 00:40:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Dec 2010 00:40:46 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 29 01:40:42 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PXk5m-0002p5-CD for geh-help-gnu-emacs@m.gmane.org; Wed, 29 Dec 2010 01:40:38 +0100 Original-Received: from localhost ([127.0.0.1]:58049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXk5l-0008Rb-Lx for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Dec 2010 19:40:37 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!news2.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.astraweb.com!border2.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:np6zr0nz/M3sl07enqG1hOXaY1w= Original-Lines: 119 Original-NNTP-Posting-Host: 30a68752.news.astraweb.com Original-X-Trace: DXC=eIhQKnFJVMj1m]JSMD?cjjL?0kYOcDh@jSBc; \8ijUdkjhD`>?RN>LaQXkmji5R; flbZ78]\S\f\n Original-Xref: usenet.stanford.edu gnu.emacs.help:183722 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:77948 Archived-At: Stefan Monnier 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