Tue 15 Aug 2017 05:33:54 PM UTC, comment #11:
This has been fixed on the default branch, and even includes some tests to ensure that the behavior continues to work.
|
Mon 16 May 2016 08:43:56 PM UTC, comment #10:
Here is a simple modification of the existing run.m that behaves properly on the example of comment #8:
What do you think?
|
Mon 16 May 2016 05:10:59 PM UTC, comment #9:
Sorry, I forgot the attachment in my previous post. Here it is.
(file #37178)
|
Mon 16 May 2016 05:06:39 PM UTC, comment #8:
I wrote below that "Matlab changes directory in all cases", and this indeed what the documentation of Matlab R2016a says (currently online at: http://fr.mathworks.com/help/matlab/ref/run.html).
Unfortunately, it seems that the truth is more complicated (arghhhhh). Here is the output of the attached example script in Matlab R2016a:
It seems that Matlab actually changes directory in all cases but one: it doesn't change directory when the input argument has no "path part" (the first output arg of fileparts is empty).
This is easy to implement,
|
Thu 05 May 2016 11:27:39 AM UTC, comment #7:
This looks about right.
The evaluation should indeed take place in the parent (using evalin ("caller", ...)) and the change back of directory should only happen if the script/function does not modify the current directory (as already implemented in the current version of run ()).
Out of curiosity, as used in your mock function, the onCleanup object is stored in the "ans" variable and might therefore be cleared before the end of the function - should it be attributed to a variable or is there something I misunderstand about onCleanup ()?
|
Wed 04 May 2016 06:34:28 PM UTC, comment #6:
So should run be just as brain-dead simple as
? Does the evaluation of the function need to happen in the parent (so instead of eval, use evalin ("caller", ...))?
|
Sat 30 Apr 2016 02:09:51 PM UTC, comment #5:
Yes, in Matlab it works even for a function that is not in the path. (But remember that Matlab changes directory before executing the function.)
|
Sat 30 Apr 2016 01:48:39 PM UTC, comment #4:
It occurs to me that the more complicated case might be if Matlab allows this to work on a function file that is not in the path. So I should amend saying it looks easy to support the cause of "run FUNCNAME", but not to support "run /path/to/some/funcfile.m". Does Matlab support that (if the directory is not in the load path)?
|
Fri 29 Apr 2016 04:12:03 PM UTC, comment #3:
> it seems simple enough to add if it's an important feature to someone.
I already lost some valuable time understanding this, so at least it's important to me ;-)
> Does Matlab also change directory to the location of the function file
Yes, Matlab changes directory in all cases.
> Does it show an error for functions that do require arguments?
Yes, exactly the same error that you get if you call the function directly: if the function actually uses the argument, you get an error; otherwise, no.
> Do errors occur in the same context as if the function were just called without run?
Not sure what you mean. I think the answer is no: you can see that run() has been called in th dbstack (run only, nothing else).
> Can errors be caught with try or shown with lasterr?
Yes (both).
|
Fri 29 Apr 2016 03:50:37 PM UTC, comment #2:
I think this has been known and ignored for a while, but it seems simple enough to add if it's an important feature to someone.
Does Matlab also change directory to the location of the function file when it is executed? What's the output for a function /some/path/foo.m
Does it show an error for functions that do require arguments? Do errors occur in the same context as if the function were just called without run? Can errors be caught with try or shown with lasterr?
|
Fri 29 Apr 2016 03:48:43 PM UTC, comment #1:
Some thoughts about this issue:
- Matlab's behaviour in this case is not clearly documented, but it is somewhat natural: in all cases, run ("toto.m") produces the same result as executing the command "toto" (assuming toto.m is on the path).
- In Octave, run() relies internally on source(). There is of course nothing wrong with source() behaving this way, since source() is an Octave-only function (perhaps should it be documented explicitely ?). The problem is that run() should not simply rely on source(), at least in this case.
|
Fri 29 Apr 2016 03:42:17 PM UTC, original submission:
The run() function of Octave treats "function m-files" (i.e., m-files where all the code appears in function/end[function] pairs) differently form its Matlab couterpart:
- Matlab executes the function without any input argument,
- whereas Octave executes the m-file as a script that defines one or several functions.
|