This is a bit off topic but this issue has not been fixed yet. Probably we should have a settings that one can prepend some more PATHs to the system-provided PATH when TeXmacs start. On macOS we should even add /opt/homebrew/bin to PATH by default.
Install TeXmacs with Maxima on mac with M1
Not even TeXmacs, I think those apps started from spotlight search or clicking the icon are not aware of you “startup shell”.
I have the same issue after switching from manually downloading the latest stand-alone maxima version 5.43 to the actual latest maxima 5.46 MacPorts version.
Since switching to MacPorts, TeXmacs can not find maxima without opening from terminal. I guess that TeXmacs somehow does not execute the .zshrc file and therefore does not get the correct PATH environment variable.
My maxima installation is located at: /opt/local/bin/maxima.
TeXmacs: 2.1.1
MacOS: 10.13.6 (High Sierra)
PS. I have re-installed TeXmacs and rebooted to no avail.
There are several suggestions around on how to set PATH on a Mac. Has anyone tried them?
https://apple.stackexchange.com/questions/51677/how-to-set-path-for-finder-launched-applications
I tried launchctl setenv PATH $PATH from my .zshrc file. But I don’t see how that could work since I want my PATH to be updated when opening TeXmacs from the Dock/Applications. ~/.launchd.conf also didn’t work. Probably due to the same issue.
I tried to set Login Items to my .zshrc file but that didn’t work. I moved my wxMaxima app out of the MacPorts folder in /Applications to be in /Applications. TeXmacs didn’t find it, though it finds:
- “/Applications/Octave-6.2.0.app/Contents/Resources/usr/Cellar/gnuplot-octave-app/5.4.0/bin”
- “/Applications/Octave-6.2.0.app/Contents/Resources/usr/Cellar/octave-octave-app@6.2.0/6.2.0/bin”
- “/Applications/Octave-6.2.0.app/Contents/Resources/usr/bin”.
Since I can not update the PATH for TeXmacs. I decided to put Maxima in the PATH for TeXmacs (/usr/local/bin).
sudo ln -s $(which maxima) /usr/local/bin/maxima
Now it works!
In the future it would be nice if TeXmacs added /opt/local/bin to the PATH since that is where MacPorts installs maxima.
I wanted to link to the MacPorts installation file to show where that is set but I can’t find which line. I’m new to MacPorts, so don’t know if installation folders are configurable.
PS. The oneliner terminal script above, creates a symbolic link in /usr/local/bin/maxima that points to your maxima installation. TeXmacs looks in /usr/local/bin, so it will find maxima when there is a link to maxima there.
It’s not exactly TeXmacs’ job to set up the environment. If it would do that, the next thing people will be complaining is it doesn’t respect their PATH variable.
The very reason for an environment variable is to pass information from the environment to a program. There’s no point in messing with it. Frankly, it’s surprising how messed up such a very important feature seems to be on Mac.
IMHO, a much better option would be to implement user overrides, along the lines of “if the user has defined a variable maxima-path and if that file exists, use it. Otherwise check the path”.
1 Like
Ever tried to modify /etc/launchd.conf as suggested here:
https://www.bounga.org/tips/2020/04/07/instructs-mac-os-gui-apps-about-path-environment-variable/
Apps launched in Finder will not spawn any shell so modify the shell configuration scripts will have no effect. An ugly fix is to launch apps from a shell with correct environment variables (the process will inherit the environment of the shell), but this is not a permanent fix.
Actually it seems this is not supported on earlier systems. The “new way” is described here; https://stackoverflow.com/questions/25385934/setting-environment-variables-via-launchd-conf-no-longer-works-in-os-x-yosemite and goes via the file ~/Library/LaunchAgents/environment.plist . Probably is better to check the manual pages of your version of MacOS. For example looking at launchctl man page there is the following command
setenv key value
Specify an environment variable to be set on all future processes launched by launchd in the caller's context.
which can be useful.
Another hint: Autodesk suggest the following method: https://help.autodesk.com/view/SGSUB/ENU/?guid=SG_RV_rv_knowledge_base_rv_setting_global_variables_osx_html which uses a service to run launchclt and set up the environment variables. Seems convoluted but makes sense and probably should also work.
It seems apple do not want to make easy to modify the environment of running applications. This indeed could have security concerns. I guess the proper way to support multiple paths is to allow the user to set up an optional TeXmacs preference to override the standard search path mechanisms in plugins. This makes sense and would not be difficult to do.
1 Like
The key here is that you should NOT modify the global PATH as some programs may rely on the BSD utilities’ behavior. A TeXmacs preference is the way to go, as @mgubi said.
I’m looking at the plugin right now and it will search also into the path TeXmacs.app/Contents/Resources/maxima/bin. So I guess a rapid solution is to symlink that directory to the directory where the executable can be found. Of course as soon as one reinstall TeXmacs this change will be lost, but in the meanwhile should work.
OK, so for everyone who has maxima installed, a work-around is the following steps:
- Open a terminal.
- Verify that
maximais correctly installed on your system by typingwhich maxima- must print a path to maxima. - Open TeXmacs.
- Verify that TeXmacs can not find maxima.
- Open a Scheme session in a TeXmacs document—from the menu: Insert->Session->Scheme (entry at the top of the Session submenu).
- Type
(getenv "PATH")to see which paths TeXmacs will examine for maxima. - Choose one of the paths (for instance
/usr/local/bin). - Symlink maxima into one of the paths you got in step 6, by typing the following in your terminal:
sudo ln -s $(which maxima) [the path you chose]/maxima
where [the path you chose] is the path you chose from step 6.
- Close and re-open TeXmacs - maxima should be detected.
This is mostly a summary of the 66 posts so far.
3 Likes
A bit late, but supporting plugins on M1 is scheduled for Mogan v1.1.2.
Mogan v1.1.2 rc4 is released, just improved the maxima support on macOS M1.
NOTE: it assumes you install maxima via homebrew and the maxima binary is in
/opt/homebrew/opt/maxima/bin
And the fix will be backported to GNU TeXmacs later after the stable release of Mogan.
2 Likes
I just saw maxima the configuration in wxMaxima and perhaps it can inspire TeXmacs developers to do something similar.
You can set the path to maxima, set environment variables and various parameters for maxima.
It looks like the Maxima program Autodetect, only did which maxima to get the path. But I’m guessing 
1 Like
I agree with you. And further more, I think plugins should be maintained outside of TeXmacs.
I planned to create a plugin center, but I am still busy working on fixing bugs.
My installation on on MacBook Air/M2, ventura 13.3.1.
maxima installed via homebrew into /opt/homebrew/bin.
I followed the following post on the apple stackexchange:
https://apple.stackexchange.com/questions/128897/how-to-use-etc-paths-d-to-add-executable-files-to-my-path:
Use /etc/paths.d/ to add a path to /opt/homebrew/bin:
I created a file in that directory. I named it homebrew-bin. I put a single line of text in it:
/opt/homebrew/bin
I need to be a superuser to be able to do that. (I did it via terminal, sudo and vim)
I then started TeXmacs app and updated the plugins (Tools/Update/Plugins).
Mirko
Don’t
You can just install your local copy of the maxima plugin and hard code the Homebrew Maxima path.
Can you explain the danger/downside of /etc/paths.d? To me the only downside is that it becomes part of PATH for all users. Otherwise, it looks very legitimate. (But, then again, I am very new to MacOS)
This directory is described in the documentation. It is read by path_helper when the shell starts - that is described in its manpage. Both /etc/profile and /etc/zprofile call path_helper.
Thanks,
When you use Homebrew you install tons of programs that have same names as the system-included ones. If you change /etc/paths.d the PATH will be changed for all apps, and some applications may not be expecting this. This is why Homebrew only set the PATH for interactive shells at install.