ESS/Matlab Path in Cocoa Emacs

ESS/Matlab Path in Cocoa Emacs

[Harold Pimentel]

Hi all,

I recently decided to switch to Cocoa Emacs. Both ESS mode and Matlab-mode work correctly and are loaded, except when I try to start R or MATLAB inside Emacs, I get the same error:

apply: Searching for program: No such file or directory, R
apply: Searching for program: No such file or directory, matlab

I suspect there is something wrong with the way Cocoa Emacs is reading my path, but I don't have enough Emacs-fu to know.

Ideas?



Thanks,

Harold

Re: ESS/Matlab Path in Cocoa Emacs

[Peter Dyballa]

Am 24.12.2010 um 20:52 schrieb Harold Pimentel:

> apply: Searching for program: No such file or directory, R
> apply: Searching for program: No such file or directory, matlab


You could either use the method with ~/.MacOSX/environment.plist (see  
for example http://www.astro.washington.edu/users/rowen/ 
AquaEnvVar.html) or you can put into your init file something like:

	(setenv "PATH" (concat "/some/directory/with/R_and_matlab" path- 
separator (getenv "PATH")))

(and also for Eacs-only EXECPATH).

A third option is to launch Cocoa Emacs from a shell script or  
AppleScript file which internally sets PATH correctly like in this  
example:

	env PATH="/some/directory/with/R_and_matlab:$PATH" open /Applications/ 
Cocoa\ Emacs

--
Greetings

   Pete

Who the fsck is "General Failure," and why is he reading my disk?

Re: ESS/Matlab Path in Cocoa Emacs

[Harold Pimentel]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Interesting.

Do you know why AquaMacs or http://vgoulet.act.ulaval.ca/en/ressources/emacs/ detect my BASH path correctly, but Cocoa does not? I'm guessing there is some plist file somewhere in the distribution?



Thanks,

Harold

On Dec 24, 2010, at 12:23 PM, Peter Dyballa wrote:
> 
> You could either use the method with ~/.MacOSX/environment.plist (see for example http://www.astro.washington.edu/users/rowen/AquaEnvVar.html) or you can put into your init file something like:
> 
> 	(setenv "PATH" (concat "/some/directory/with/R_and_matlab" path-separator (getenv "PATH")))
> 
> (and also for Eacs-only EXECPATH).
> 
> A third option is to launch Cocoa Emacs from a shell script or AppleScript file which internally sets PATH correctly like in this example:
> 
> 	env PATH="/some/directory/with/R_and_matlab:$PATH" open /Applications/Cocoa\ Emacs
> 
> --
> Greetings
> 
>  Pete
> 
> Who the fsck is "General Failure," and why is he reading my disk?
> 


[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

Re: ESS/Matlab Path in Cocoa Emacs

[Peter Dyballa]

Am 25.12.2010 um 10:46 schrieb Harold Pimentel:

> Do you know why AquaMacs or http://vgoulet.act.ulaval.ca/en/ressources/emacs/ 
>  detect my BASH path correctly, but Cocoa does not? I'm guessing  
> there is some plist file somewhere in the distribution?


No, I don't know (except that AquaMacs is using some hack). What I  
know is that in Mac OS X processes are not launched as in other UNICes  
with the aid of a shell. Outside of Mac OS X these processes inherit  
(almost) the same environment as your interactive command shell  
(almost, because bash allows to set up the interactive environment  
differently from the one for batch use). You can achieve a bit with / 
private/etc/bashrc, I think. In Snow Leopard, Mac OS X 10.6, /private/ 
etc/paths.d (and /private/etc/manpaths.d) are provided to give you  
lots of time to go shopping while logging in... (this is my experience  
with this scheme in Mac OS X 10.5, Leopard)

The working way, since the times of the NeXT Cube, is ~/.MacOSX/ 
environment.plist. Because *all* processes inherit their environment  
from this file.

--
Greetings

   Pete

To most people solutions mean finding the answers. But to chemists  
solutions
are things that are still all mixed up.

Re: ESS/Matlab Path in Cocoa Emacs

[Stefan Monnier]

> No, I don't know (except that AquaMacs is using some hack). What I know is
> that in Mac OS X processes are not launched as in other UNICes  with the aid
> of a shell.

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.  Tho since the problem has been known for so many years and
affects so many programs that maybe recent gdm startup scripts have
finally tried to attack this problem rather than keep waiting to hope
complaining-users will just go away?


        Stefan

Re: ESS/Matlab Path in Cocoa Emacs

[Peter Dyballa]

Am 28.12.2010 um 03:40 schrieb Stefan Monnier:

> 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  
usually a shell script, in which for example the path to fonts is set,  
the X key or modifiers map is being modified – why not work on PATH  
(and MANPATH, INFOPATH, ...) as well? Couldn't a simple

	. ~/.login

or rather

	. ~/.profile

or even better

	. ${HOME}/.profile

help and set everything for X11?

--
Greetings

   Pete

What is this talk of 'release?' Klingons do not make software  
'releases.'  Our software 'escapes,' leaving a bloody trail of  
designers and quality assurance people in its wake.

Re: ESS/Matlab Path in Cocoa Emacs

[Stefan Monnier]

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


        Stefan

Re: ESS/Matlab Path in Cocoa Emacs

[Peter Dyballa]

Am 28.12.2010 um 15:22 schrieb Stefan Monnier:

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

Hardlink both!

> or does it use neither?
> or does it depends on the kind of session you choose at login? ...)


On Linux you have the *trace family of commands to find out exactly  
what happens, which files and directories are opened... See below!


I think I never came into such a mess! Could work with simple X11. My  
prayers were obviously answered.

--
Greetings

   Pete

A child of five could understand this!  Fetch me a child of five.

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

Re: ESS/Matlab Path in Cocoa Emacs

[Tan]

Peter Dyballa <Peter_Dyballa <at> Web.DE> writes:

> 
> 
> Am 24.12.2010 um 20:52 schrieb Harold Pimentel:
> 
> > apply: Searching for program: No such file or directory, R
> > apply: Searching for program: No such file or directory, matlab
> 
> You could either use the method with ~/.MacOSX/environment.plist (see  
> for example http://www.astro.washington.edu/users/rowen/ 
> AquaEnvVar.html) or you can put into your init file something like:
> 
> 	(setenv "PATH" (concat "/some/directory/with/R_and_matlab" path- 
> separator (getenv "PATH")))
> 
> (and also for Eacs-only EXECPATH).
> 
> A third option is to launch Cocoa Emacs from a shell script or  
> AppleScript file which internally sets PATH correctly like in this  
> example:
> 
> 	env PATH="/some/directory/with/R_and_matlab:$PATH" open /Applications/ 
> Cocoa\ Emacs
> 
> --
> Greetings
> 
>    Pete
> 
> Who the fsck is "General Failure," and why is he reading my disk?
> 
> 

Hi Peter,

Greetings. It took me sometime to find this post as I tried really
hard to get the matlab mode working.

The third method works for me, I have:

$ env PATH="/Applications/MATLAB_R2012a.app/bin/matlab:$PATH" open
/Applications/Emacs.app

However the init file method doesn't work. I put in my init file:

(setenv "PATH" (concat "/Applications/MATLAB_R2012a.app/bin/matlab" ":" (getenv
"PATH")))

Emacs still shows the "no such file or directory" error message.

Any idea? Thanks a lot!

Best,
Tan

Re: ESS/Matlab Path in Cocoa Emacs

[Peter Dyballa]

Am 16.06.2012 um 04:42 schrieb Tan:

> (setenv "PATH" (concat "/Applications/MATLAB_R2012a.app/bin/matlab" ":" (getenv
> "PATH")))
> 
> Emacs still shows the "no such file or directory" error message.
> 

Try to use the above statement, a bit altered:

	(setenv "PATH" (concat "/Applications/MATLAB_R2012a.app/bin" ":" (getenv "PATH")))

(I presume the "matlab" file in the "/Applications/MATLAB_R2012a.app/bin" directory is already the executable, so it may not appear in PATH because then the matlab executable would be searched for in the not existing *directory* /Applications/MATLAB_R2012a.app/bin/matlab), maybe plus the following one:

	(setq exec-path (split-string (getenv "PATH") path-separator))

The variable exec-path is responsible for supplying sub-processes in GNU Emacs with a search path for executables. You can also customise this variable, but would need to edit it when it changes when Matlab gets updated – just as with the "(setenv "PATH" ...)" statement.

--
Greetings

  Pete

Almost anything is easier to get into than out of.
				– Allen's Law