Just a remark, "source" is the more normal keyword in UNIX for reading commands from a file.  Even if the functionality becomes identical to run.m it might still be nice to have the alias.  For example, we keep "chdir" as an alias for "cd" because people like both.

Second, there are differences.  The "source" command can take an additional CONTEXT option of "base" or "caller" to determine where the script is executed.  This is not part of run.m

Markus: Thanks for checking.

I beginning to think we should attempt to make "run"Matlab compatible (as much as possible) and independent from "source".

But then what is the best/correct thing for "source" to do?  If it is just another name for "run" then we might as well deprecate and remove it.  But if there is something else that it can do differently from "run", what is that?  How should it behave for files that contain functions or classdef classes (for example)?

The attached change appears to help, but something strange still happens when sourcing files that are functions instead of scripts.

With the change, I see the following:

>> source foo  ## Does not automatically append .m
error: source: error sourcing file '/tmp/foo': no such file, '/tmp/foo'
>> source foo.m  ## Improved error reporting:
error: source: error sourcing file '/tmp/foo.m': parse error near line 1 of file /tmp/foo.m

  syntax error

>>> (1))
        ^
>> source foo.m  ## Syntax error fixed; code executed
ans = 1
>> type foo.m  ## Make it a simple function instead:
foo.m is the user-defined function defined from: /tmp/foo.m

function foo ()
  'this is FOO!!'
end

>> source foo.m  ## Source works, but function not executed
>> foo           ## Is it defined?  Yes.
ans = this is FOO!!
>> which foo     ## Hmm, this seems wrong.
'foo' is a command-line function

So it seems that when we parse the file, it is being entered into  Octave's table of known functions.  But I'm not sure that's the best thing to do.

Note that the existing code has the comment

// For compatibility with Matlab, accept both scripts and functions.

but I don't think Matlab has the "source" function.  So I assume this comment was added because Octave's "run" function (which Matlab does have) calls "source", and Matlab's "run" function will execute functions that have no arguments.

I'm curious to know whether Matlab's "run" function parses the file every time, or whether it caches the result.  We should be able to test as follows.  Create a file foo.m with the contents

function foo ()
  persistent val
  if (isempty (val))
    val = 1
  else
     val = val + 1
  end
end

then execute

run foo.m
run foo.m

Does it print val = 1 each time, or is val incremented or is there some error?


(file #49704)

I was told I should paste this case, where I call source with the exact filename, too.

octave:2> source foo.m
parse error near line 1 of file /tmp/foo.m

  syntax error

>>> (1))

       ^

This 'works' as expected. There is no bug in this case.

If it's called foo.m, you would have to call "source foo.m" -- source does not automatically append ".m" like run does. I think that in your first invocation you indeed called "source foo.m", giving you the parse error, and in the second you called "source foo", receiving the error that "foo" does not exist (which would be correct).