octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

source command inconsistencies


From: Mike Miller
Subject: source command inconsistencies
Date: Fri, 2 Feb 2018 12:39:07 -0800
User-agent: Mutt/1.9.2 (2017-12-15)

Hi,

I ran across a weird inconsistency with the source function. This also
applies to calling octave with an m-file argument on the command line,
which effectively calls source.

This only applies to function files, m-files that begin with a function
declaration that are meant to be installed on the load path and called
by name.

Consider this example

    $ cat testfunc.m
    function testfunc ()
      disp ("This is testfunc!");
    endfunction

Now let's say testfunc is in pwd

    >> source testfunc.m
    This is testfunc!
    >> source ./testfunc.m
    This is testfunc!
    >> which testfunc
    'testfunc' is a function from the file /…/testfunc.m

This works because pwd happens to be on the load path. And because the
name 'testfunc' is already in the symbol table, Octave calls it with no
arguments.

Now let's say it's in the parent of pwd which is not on the load path

    >> source ../testfunc.m
    >> 
    >> which testfunc
    'testfunc' is a command-line function

In this case Octave parses the file as script input, defines testfunc as
if it had been entered at the command prompt, and does not call it.

So already, depending on whether the full path to filename is contained
in the load path or not, we have different behavior from the source
function.

There is one more case I can't figure out. If I source the file multiple
times using a relative file name, nothing changes each time. Same with
an absolute file name. But if the argument to source starts with a
tilde, then this happens

    >> which testfunc
    >> source ~/../../tmp/foo/testfunc.m 
    >> source ~/../../tmp/foo/testfunc.m 
    This is testfunc!
    >> which testfunc
    'testfunc' is a command-line function

For some reason on the second call Octave can now call the function
directly.

Does anyone else see these inconsistencies as a problem?

As a bonus I think it would be very nice if

    $ octave /path/to/some/function/file/something.m

were able to call the function if it is a function file instead of a
script.

-- 
mike

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]