Executing unix commands set in PATH in matlab does not work with unix command

Greetings,

When running the "unix" command in matlab, i.e.: unix('<unix_command>') I get an error, the unix command is not found in /bin/bash. Interestingly, other commands work with the unix command, e.g.: unix('who'). Also of note, running "echo $SHELL" in the terminal window returns "/bin/bash". The command I am trying to run is part of a package that is set in my PATH.

Any help you might offer would be greatly appreciated-

[Walter Roberson]

What is shown if you

unix('echo $PATH')

And does it match the PATH that was set before you started MATLAB? (except that starting MATLAB probably added MATLAB directories to the PATH) ?

Answer 1

[Walter Roberson]

PATH = getenv('PATH');
setenv('PATH', [PATH ':/usr/local/desiredpath']);

unix('commandofinterest')

[Matthew]

Thank you Walter, it seems to be working.

[Monique]

Thank you Walter! 5 years later and this answer is still helpful

[Makis]

Great this worked.

Answer 2

[Miriam]

Hi,

Following up on this, I encounter a similar problem for unix commands (Ubuntu, Win 10).

I can call basic unix functions from Matlab directly (for example !ubuntu -c ls) but I can’t access a specific program (which lives in /home/myname/abin) or any of its functions which I would like to run from Matlab.

When I set the path to access the directory of this program in Matlab using setenv, the path is indeed set correctly. But whatever function I am trying to run, with using !myfunction or unix(myfunction) or !ubuntu myfunction, I get the error “myfunction is not recognized as an internal or external command, operable program or batch file.“ (or similar for the other calls).

I think this might be related with Windows being blind for Ubuntu directories or not having permission to access them but even setting the path directly to Ubuntu files stored in Windows (as decribed here: https://www.howtogeek.com/261383/how-to-access-your-ubuntu-bash-files-in-windows-and-your-windows-system-drive-in-bash/ ) does not do the job.

Before I reinstall Matlab in Ubuntu only to be able to access this program, does anyone know how to solve this problem?

Answer 3

[Ken Atwell]

MATLAB does not source your BASH shell resource file, so anything established in that file may not be available to the unix command.

First check your PATH as Walter recommend, and if it is not to your liking, you can use setenv to include the directories you need.

[Matthew]

Hi Ken,

Thank you for your answer. I am just getting back at this, and still having problems.

I would like to run unix commands in matlab, but the path is not correct. i.e.

Running:

unix('echo $PATH')

Prints:

/usr/bin:/bin:/usr/sbin:/sbin

I would like /usr/local/desiredpath to be added to the path. But, when I run

unix('setenv PATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/desiredpath"')

Prints:

/bin/bash: setenv: command not found

ans =

127

Thus, I ask if you might know what my problem is.

Again, the main problem is that I cannot run a command found in /local/bin/desiredpath using the unix command in matlab (prints: /bin/bash: <commandofinterest>: command not found).

Thank you,

Matthew

[Walter Roberson]

The setenv is working, but setenv only affects the environment of the shell it runs in, and after the unix() call to set that variable ends, that shell is gone.

[Walter Roberson]

Correction, not all shells understand "setenv". The bash syntax would be

export PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/desiredpath"

but even with this, it only affects the environment of the shell it runs in and after the unix() call that set the variable ends, that shell is gone.

[Matthias Fripp]

@Walter Roberson, the setenv command is a Matlab command; it should be run directly on the Matlab command line, not via system() or unix(). When run from within Matlab, it modifies the environment within which Matlab is running, and that affects all subsequent unix() or system() calls.

[Walter Roberson]

Matthew had used

unix('setenv PATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/desiredpath"')

which is only valid syntax for csh derivatives. Setting the environment from within the command to be unix()'d is a valid approach, but these days typically involves an "export" command.

Answer 4

[Carmine]

Hello, I'm still getting the same error:

unix('ls')

gives

ans=127

even though I've added /bin to the path. Calling unix('/bin/ls') also gives 127. Any possible other solutions?

[Walter Roberson]

You have likely defined a variable named "unix", or else have defined your own function named "unix". Check with

which -all unix

Answer 5

[Carmine]

Thanks for you comment, Walter. No, I get the following:

>> which -all unix

built-in (/usr/local/common/matlab_2013b/toolbox/matlab/general/unix)

Also, if I try system('pwd'), I get 127.

If I run Matlab on another machine, the commands work fine. Somewhere, there is a difference between the two machines, or my environment setup. I am wondering where I should look to find that difference. getenv('LD_LIBRARY_PATH') give the same paths on both machines.

[Walter Roberson]

How about

!pwd

?

My guess: you have configured your shell to source a file each time a shell is started, but the commands inside it rely upon being sourced from a shell that has terminal access. Shells started with unix() or system() do not have an associated terminal.

The file being sourced that I am referring to is probably not /etc/profile or ~/.bash_profile or ~/.bash_login or ~/.profile as those are the ones checked for interactive login, which would not be the case in this situation. However, ~/.bashrc would be used for interactive non-login shells, and for any shell the environment variable BASE_ENV is checked and if it refers to a file then the file is sourced. But if the shell was invoked as "sh" instead of as "bash" then some of the above files are skipped and the environment variable examined is ENV instead of BASE_ENV

The most common startup command that causes problems is "tset" to try to query the user to set the terminal type, especially in the form

eval `tset -s -m ... `

Such a command needs to be protected by testing to see if a terminal is defined, such as by using

[[ -t 0 ]] && eval `tset -s -m ... `

which checks that file descriptor 0 (stdin) is associated with a terminal before it goes ahead with the tset.

[Carmine]

No, that doesn't work either (it gives no output at all).

>>!pwd

>>

And I am not using tset anywhere.