bugGNU Octave - Bugs: bug #58780, 'source' throws unexpected syntax...

 
 

bug #58780: 'source' throws unexpected syntax error.

Submitter:  Martin Castillo <castilma>
Submitted:  Sat 18 Jul 2020 03:17:32 PM UTC
   
 
Category:  Interpreter Severity:  2 - Minor
Priority:  3 - Low Item Group:  Unexpected Error or Warning
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 30 Oct 2020 08:59:54 PM UTC, comment #9: 

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

Rik <rik5>
Group administrator
Mon 26 Oct 2020 08:31:54 AM UTC, comment #8: 

This item needs more careful thought.  Changing the behavior of "run" or "source" should not happen right before a major release.

Marking as "dev".

Kai Torben Ohlhus <siko1056>
Group Member
Thu 27 Aug 2020 01:58:36 PM UTC, comment #7: 

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)?

John W. Eaton <jwe>
Group administrator
Thu 27 Aug 2020 07:42:14 AM UTC, comment #6: 

With Matlab R2020a, I see the following for the test from comment #5:

>> run foo.m
run foo.m

val =

     1


val =

     2


Markus Mützel <mmuetzel>
Group administrator
Mon 24 Aug 2020 08:58:19 PM UTC, comment #5: 

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)

John W. Eaton <jwe>
Group administrator
Mon 20 Jul 2020 05:46:03 AM UTC, comment #4: 

Thank you for your bug report.  I can confirm the issue for Octave 6 and 7.


__octave_config_info__.hg_id
ans = 713398d4a3c3


I do not think that it is super important to be fixed, but the interpreter acts a little weird here.  I cannot reliably say when "source" really parses the file and when not.  Maybe the documentation could be more verbose about it.

https://www.octave.org/doc/v5.2.0/XREFsource.html

e.g.


Parse and execute the contents of "file", where "file" is an absolute or relative path to a file.


In this case any call to "source foo" should error.

Kai Torben Ohlhus <siko1056>
Group Member
Sun 19 Jul 2020 10:42:00 PM UTC, comment #3: 

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.

Martin Castillo <castilma>
Sun 19 Jul 2020 10:38:40 PM UTC, comment #2: 


> source does not automatically append ".m" like run does.


This is exactly what I want to report. In the case, that foo.m exists but has a syntax error, source does add ".m" to the filename.

Martin Castillo <castilma>
Sat 18 Jul 2020 07:19:26 PM UTC, comment #1: 

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).

Michael Leitner <mleitner>
Sat 18 Jul 2020 03:17:32 PM UTC, original submission:  

Sorry for weird title.

1) Create foo.m with a syntax error in the current directory.
foo.m:
(1))

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

  syntax error

>>> (1))

       ^

3) correct the file (remove last parantheses) and try to source again.

octave:1> source foo
error: no such file, '/tmp/foo'
error: source: error sourcing file '/tmp/foo'

So now it doesn't seem to look for foo.m anymore. But it's weird that it looked at it when it was wrong.
This surprised me a little bit, but might be wanted. I.e., function files can be sourced with the function name, but for source files, the whole filename needs to be passed. And so it has to read foo.m, to check, whether it is a function or not.

Martin Castillo <castilma>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49704:  source-diffs.txt added by jwe (3KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by mleitner (Posted a comment)
  • -email is unavailable- added by castilma (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-26 siko1056 Release6.0.90 dev
    2020-08-24 jwe Attached File- Added source-diffs.txt, #49704
        StatusConfirmed Need Info
    2020-07-20 siko1056 CategoryNone Interpreter
        Severity3 - Normal 2 - Minor
        Priority5 - Normal 3 - Low
        StatusNone Confirmed
        Release5.2.0 6.0.90

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code