Thanks, @Tilda. I believe that MATLAB interprets what follows the -r switch as a command, so it sees the / in the path as a division operator.
It may work with the -sd switch which specifies the startup folder.
Getting the Matlab Plugin Working with TeXmacs
Seems like the environment variable should be MATLABPATH, not MATLAB_PATH:
https://uk.mathworks.com/help/matlab/matlab_env/what-is-the-matlab-search-path.html
Thanks a lot @jeroen!
using the -sd switch was the ticket. So the plug-in startup tm_matlab looks like this now:
#!/bin/bash
echo -ne "\002verbatim:"
export PLUGIN_CODE=$TEXMACS_HOME_PATH/plugins/matlab/code/
export MATLAB_BASH=/Applications/MATLAB_R2020a.app/bin/
MATLABPATH="$MATLAB_BASH:$PLUGIN_CODE"
exec matlab -nodesktop -nosplash -sd ${PLUGIN_CODE} -r tmrepl
Definitely not the most elegant code but it works. 
I guess @pireddag should be able to adjust the location of files and directories easily to his Linux needs.
Cheers, Tilda
Hi again @Tilda.
IMHO the plugin code needs to take into account the startup.m. In my “vast” experience (I have talked to only one other person about Matlab startup!) startup.m is used by many people … apart the joke on the vast experience, it is a sensible thing that the plugin code takes startup.m into account.
One of the things that the startup may do is to change the initial Matlab directory, and I do not know whether the -sd switch supersedes that, as I have Matlab R2011b which does not support it so I can’t test it (my guess is that it does not, I assume that startup is run after -sd fixes the directory).
Moreover, I feel that users would like to start from the directory that they defined in the startup.
My proposed tm_matlab is therefore
#!/bin/bash
echo -ne "\002verbatim:"
PLUGIN_CODE_PATH=$TEXMACS_PATH/plugins/matlab/code/
export MATLAB_BASH=/Applications/MATLAB_R2020a.app/bin/
export MATLABPATH="$MATLABPATH:$MATLAB_BASH:$PLUGIN_CODE_PATH"
matlab -nodesktop -nosplash -r tmrepl
where
- I have added the PLUGIN_CODE_PATH to the MATLABPATH (recursively, so that if the user already has a MATLABPATH, we add to it)
- I have exported the MATLABPATH, so that the
matlabprocess will see it (as far as I understand, you have to export environment variables so that child processes (I hope this is the correct expression) can see them.
Besides this, I did not understand what the MATLAB_BASH variable does, I have therefore left it there.
Finally, for invoking Matlab commands which include slashes, you can include them in quotes. An example is
matlab -nodesktop -nosplash -r "addpath(fullfile(getenv('TEXMACS_PATH'),'plugins/matlab/code')); tmrepl"
which I did not use in the script because I liked the one with MATLABPATH better 
.
Pls. let me know if this looks sensible.
Giovanni
1 Like
Thanks for the clarification @pireddag! I agree, using -sd may not result in what a user would expect. Your solution seems a good one.
I don’t think MATLAB_BASH needs to be on the MATLAB search path. It doesn’t contain any .m files, so it doesn’t need to be searched.
Dear @pireddag,
thanks for the significant improvements of the startup script and your concise explanations. The MATLAB_BASH variable is some code junk that’s been left over from some previous attempts, and, as @jeroen has rightly remarked, doesn’t contain anything useful and should no longer be in the script.
So, the cleaned-up version of your tm_matlab is therefore:
echo -ne "\002verbatim:"
PLUGIN_CODE_PATH=$TEXMACS_PATH/plugins/matlab/code/
export MATLABPATH="$MATLABPATH:$PLUGIN_CODE_PATH"
matlab -nodesktop -nosplash -r tmrepl
I’ve tested it; it reads in startup.m, and works very, very nicely!!
Thanks again, @pireddag and @jeroen for your expertise.
Cheers, Tilda
1 Like
Looking forward to your pull request (I am not part of the developers’ team, @darcy will look after it).
Dear @pireddag,
I’ve finished writing the documentation files, and I’ve also set README.md on GitHub. But now I’m stuck and don’t know how to upload the matlab*.tm files.
Tilda
Hi @Tilda,
I think the way to send the pull request is the following.
First fork the repository to which you would like to send the pull request (in this case https://github.com/texmacs/matlab); then modify your fork; then open a pull request from your fork.
If you are working on your fork, you can upload your files by drag and drop.
Please have a look at the README.md of https://github.com/texmacs/notes (section “To contribute”); the steps are the same as far as I understand—and you do not need to work locally, so you don’t need to clone/add/commit on your computer: as I wrote above, drag and drop works, then you can open the pull request through the web interface as well.
I have just a little experience with version control systems and with git in particular: in part by experience and in part by guessing, working locally is quicker and puts more powerful tools at your disposal, but you have to invest some time at the beginning to learn it.
Said this, I expect that you will be able to fork/modify/send the pull request using only the web interface.
Let me know if this works!
G.
My impression is that you need only to press the green button (and maybe some other button after that!) to submit the pull request.
For the Windows part: IMHO it will be necessary to prepare the plugin for Windows as well (that the software works for the users is more important than our preferences IMHO), but please do not feel pressed to do that yourself. I would need some time to figure how to do it.
Giovanni
You’re right about the batch file for windows, I guess. And thanks that you’re willing to do that one of these days.
As it says
… wants to merge 2 commits into texmacs:master from …
on Github, I suppose the pull request is opened. Thanks again for your help.
Cheers, Tilda
1 Like
I am guessing that I have a chance—if it is too complicated, I will give up
isn’t there a bash shell for windows? If so, windows users might then be quite happy with our shell script.
Tilda
As far as I understand (just read on the Internet), that system allows one to install a Linux distribution within Windows. We would like to run the Windows version of Matlab through the Windows version of TeXmacs, which is a different thing.
I have been able to do something, and figured out that Matlab for Windows does not set the path based on the MATLABPATH environment variable—it does use that variable, but only to figure out where its own toolboxes are, I will write about this in more detail.
The command with addpath should then work, I still need to test it.
Said this, I have another concern about the shell script for Linux. What happens to the MATLABPATH environment variable if we stop and restart a Matlab session from the same TeXmacs document, or if we start several instances of TeXmacs from the same shell process? Do we get duplicated strings of $PLUGIN_CODE_PATH in it? If so, should we prevent it?
I don’t think so, export should only pass variables to child processes. E.g. you can test putting
export PATH=$PATH:/bin/test
echo $PATH
in a bash script. It will append to your PATH, but when it returns, you can check with another echo $PATH that it is untouched.
1 Like
my impression is that once Matlab is launched, the plugin-startup script in not run again, irrespective of how often Matlab commands are executed from within TeXmacs files.
Yes, that’s generally correct @Tilda. Normally only one MATLAB session is launched. However, there is a function in TeXmacs to kill that session and restart it. This can for example be useful if your code is stuck in an infinite loop. In this case the session startup code would be re-run the next time you enter a command.
If the process is dead, it needs to be Bourne again 
As I previously mentioned, it’s not such a good idea to terminate a Matlab process within TeXmacs, at least not on OSX. To avoid “abnormal termination” due to a “segmentation violation” creating matlab_crash_dump.xxxx-y -files in $HOME, it’s probably better to kill Matlab on the operating system level.