How to check if eval() changes values of any local variables?

Dear all,

I have a GUI that lets users to evaluate custom scripts, mostly problem oriented functions. The scripts for running need to create some temporary variables and I would like to make sure that they don’t mess up the local workspace. Is there any clean and neat way to do?

Thank you for your help, Kirill Andreev

Answer 1

[Walter Roberson]

No, it is always possible to escape from eval() and do arbitrary things. What-ever mechanisms MathWorks uses for the Contents are not available to users.

If you want security, do not use eval() on user input without having proven the input to be harmless (which is generally a tough task.)

Answer 2

[Sean de Wolski]

Package their script into a function (using fopen/fwrite/fprintf so that it uses its own local workspace. Call the function.

Waallaa! No eval and no poofing

[Walter Roberson]

Until the user writes

assignin('caller', 'OneOfYourVariables', SomeRandomValue)

Also, unless you use a different function name each time, be sure to "clear" the function name after you generate the new .m file or Strange Things Will Happen.

[Kirill Andreev]

Thank you everyone. I will try this function-wrapping suggestion. I understand that it would be hard to do it completely fool proof but I need something better than simple eval(). Most of the users who is going to use this application are going to run it as a complied GUI and I would consider it a very rare event if anyone will insert statement assignin() or similar.

Right now, before executing an external script, I dump all my local variables on disk and as soon the script is finished I resuscitate them. It is not very time efficient so I wondered if there is a better way.

[Sean de Wolski]

Rather than saving them to disk you could set them to appdata, which will be MUCH faster:

doc setappdata/doc getappdata

Answer 3

[Jan]

You can shadow assignin by creating an own function with the same name. Then you can catch the 'base' and 'caller' argument and collect all changes separately from the actual workspace.

As long as the users can call eval, strange this will happen - promissed! Somebody will create a variable called 'load' and you will not be able to load the variable dump any longer.

[Walter Roberson]

And then the user will create a variable named "builtin"...

[Kirill Andreev]

Generally speaking, as far as Matlab lets create variables with assignment operator and variables are given preference over functions, I am out of luck… It turns out that it is not completely true.

I was playing with clearvars function just to delete all local variables assigned by external script and reload all my variables from the disk. It turned out that clearvars is still treated by Matlab as a function after calling external script even if clearvars was used as a variable inside the script. Apparently, preference rules are different for variables created by eval() and for variables created in a usual way. Below couple examples. In first one clearvars is a variable as expected. And in the second one it is treated as a function even if a variable with the same name is created by eval(). I don’t know though if it is documented behaviour to rely on it.

function eval_test

clc

myvar = 10;

% eval('clearvars = 10;');

clearvars = 10;

clearvars

whos

====================

clearvars =

10

Name Size Bytes Class Attributes

ans 1x1 8 double

clearvars 1x1 8 double

myvar 1x1 8 double

>>

function eval_test

clc

myvar = 10;

eval('clearvars = 10;');

%clearvars = 10;

clearvars

whos

=================================

not output produced