external (! echo $PATH) in Matlab for MacOSX

24 views (last 30 days)
Jesús
Jesús on 24 Feb 2019
Edited: Joshua Carmichael on 5 Feb 2026 at 20:19
Hi:
I am using several scripts.m in matlab. These scripts use external terminal commands located in several directories.
The problem is that the "!echo $PATH" answer is different when starting matlab by double click and starting matlab as a terminal command
double click:
>> !echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin
terminal command:
>> !echo $PATH
/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
How can I change this behaviour?
Regards
jpeinado
  2 Comments
Geoff Hayes
Geoff Hayes on 25 Feb 2019
J - I observe the same behaviour...but why is that important? How are you using !echo $PATH in your code?
Geoff Hayes
Geoff Hayes on 25 Feb 2019
Edited: Geoff Hayes on 25 Feb 2019
J's answer moved here
Hi Geoff:
Both paths are different. The problem is not the !echo PATH command
This is important because in my code, I use some terminal commands.
The commands are found when MATLAB uses the second path, not the first one.
What I wanted to know is how can I configure MATLAB for using the same path in both cases. When starting MATLAB from the terminal, the path is obtained from bash. But I dont know how to get this path when staring MATLAB by clicking on Finder.
jpeinado

Sign in to comment.

Answers (3)

Jesús
Jesús on 25 Feb 2019
Hi Geoff:
You edited my question as yours. What happened?. is this a mistake?
jpeinado
  2 Comments
Geoff Hayes
Geoff Hayes on 25 Feb 2019
Edited: Geoff Hayes on 25 Feb 2019
I just deleted your answer and made it into a comment (since it wasn't an answer to the question). Just like your "answer" here should be a comment to the thread above.
Jesús
Jesús on 25 Feb 2019
Moved: Walter Roberson on 4 Feb 2026 at 19:47
Thank you very much Geoff.
Please if possible edit my comment...change stating-->starting :-)
jpeinado

Sign in to comment.


Joshua Carmichael
Joshua Carmichael on 4 Feb 2026 at 19:23
Edited: Joshua Carmichael on 5 Feb 2026 at 20:19
The following text and code is applicable to the simple case in which the user's zprofile (or other profile) includes paths separated by colons, and is not set by a command. It can't handle the command-setting case. Original text follows:
I have the same problem. My !echo $PATH does not match what echo $PATH outputs from my terminal. My shell is zsh. I did the following. It seemed to work and may be an easy solution (I'll paste this answer to similar questions on the Community too). First, open Matlab (not terminal).
text = fileread('~/.zprofile');
str1 = split(text,{':'}); %path additions separate by colons.
str1 = cellfun(@deblank, str1, 'UniformOutput', false); %omit newlines, etc...
str1 = strcat(':',str1(:));
for k = 1:length(str1)
path1 = getenv('PATH');
setenv('PATH', [path1 str1{k}]);
end
This code sits in my startup.m file. It worked so I could run my external code.
  4 Comments
Walter Roberson
Walter Roberson on 5 Feb 2026 at 20:09
The point is that your provided code only works for the simple case where the .zprofile currently contains a single line setting the path, and does not work for cases where the path is computed somehow or where it sets other environment variables or does anything else.
Joshua Carmichael
Joshua Carmichael on 5 Feb 2026 at 20:17
Edited to reflect it's applicable to only certain simple cases. Thank you.

Sign in to comment.


Walter Roberson
Walter Roberson on 4 Feb 2026 at 20:11
It is completely normal that the PATH when starting from icon is different than the PATH when started from terminal window.
When started from icon, the process is forked off of some layer above the finder process, and the environment is only what is given to daemon processes.
When started from terminal, an additional shell startup procedure is done when creating the terminal process, and the shell startup procedure normally expands the PATH.
The shell startup procedure depends on which login shell is configured. For example if zsh is configured, then
Commands are first read from /etc/zshenv; this cannot be overridden. Subsequent behaviour is modified by the RCS and GLOBAL_RCS
options; the former affects all startup files, while the second only affects global startup files (those shown here with an path
starting with a /). If one of the options is unset at any point, any subsequent startup file(s) of the corresponding type will not be
read. It is also possible for a file in $ZDOTDIR to re-enable GLOBAL_RCS. Both RCS and GLOBAL_RCS are set by default.
Commands are then read from $ZDOTDIR/.zshenv. If the shell is a login shell, commands are read from /etc/zprofile and then
$ZDOTDIR/.zprofile. Then, if the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the
shell is a login shell, /etc/zlogin and $ZDOTDIR/.zlogin are read.
On the other hand if ksh is configured
/etc/profile
The system wide initialization file, executed for login shells.
$HOME/.profile
The personal initialization file, executed for login shells after /etc/profile.
$HOME/..kshrc
Default personal initialization file, executed for interactive shells when ENV is not set.
These procedures are fundamentally different, so there is no reasonable way for processes spawned from daemon to guess the "right" one to execute, considering that processes spawned from daemon have no associated shell.
With a fair bit of effort (difficult to find straight current documentation on it), it at least used to be possible to extend the PATH for daemon processes -- but any such extension would have to be static. It is not possible to interpose a login shell between the master daemon process and all processes started from daemon, so the most you could do is to add static entries such as /opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin to the PATH, missing out on whatever local customizations that individual users had done to their PATH.
Adding entries to the daemon PATH is hard to find documentation for in the Catalina and later time frame. Previous techniques such as editting a system-wide plist no longer work. As best I have been able to tell, these days you are supposed to edit the plist associated with the individual application, such as /Applications/MATLAB_R2025b.app/Contents/Info.plist . If I recall correctly, when I experminted with that a couple of years ago, I was not able to get it to work.

Categories

Find more on Startup and Shutdown in Help Center and File Exchange

Products


Release

R2017b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!