pathdef, savepath, ocaverc and Matlab

[Ben Abbott]

On Jan 3, 2008, at 5:37 PM, Ben Abbott wrote:

>
> On Dec 31, 2007, at 12:30 PM, Ben Abbott wrote:
>
>>
>> On Dec 31, 2007, at 1:12 AM, Ben Abbott wrote:
>>
>>>
>>> On Dec 31, 2007, at 12:49 AM, John W. Eaton wrote:
>>>
>>>> The savepath function only exists for compatibility with Matlab, so
>>>> whatever it does should be compatible.
>>>>
>>>> jwe
>>>
>>> Good point.
>>>
>>
>> I've spent some time looking over the differences between Matlab  
>> and Octave regarding path related functions. I've enumerated what I  
>> found below.
>>
>> (1) pathdef: In Octave, pathdef() load's the virgin default path.  
>> In Matlab pathdef.m is a script created by savepath.m, and  
>> pathdef.m is used to setup Matlab's path each time Matlab is run.
>>
>> (2) savepath: In Octave, savepath.m saves to current working path  
>> to ~/.octaverc. In Matlab, it saves the current working path to  
>> pathdef.m. On my Mac, Matlab doesn't require admin access to  
>> execute savepath.m ... Can someone tell us if it does on Linux?
>>
>> (3) restoredefaultpath: In Matlab this allows a user to restore the  
>> working path to its virgin form. It only impacts the current  
>> session. In Octave, this may be done by path (pathdef);
>>
>> (4) matlabroot: In Matlab this returns the path to the root of  
>> Matlab's installation directory. The Octave equivalent is  
>> OCTAVE_HOME.
>>
>> (5) matlabrc: In Matlab matlabrc.m is supposed to have admin access  
>> (?) and is run each time Matlab is started. It is located in  
>> <matlabroot>/toolbox/local. The Octave equivalent [of startup] is  
>> octaverc located in octave-home/share/octave/version/m/startup.
>>
>> (6) startup: In Matlab startup.m is run (if it exists in the path)  
>> each time Matlab is started, but only after matlabrc.m. The Octave  
>> equilvalent is ~/.octaverc.
>>
>> (7) finish: In Matlab finish.m is run upon a clean exit. From what  
>> I can tell there is no Octave equivalent.
>>
>> There are many differences. Some will require changes to c-code  
>> while the majority require changes to m-files.
>>
>> I'm up to the task of handling the m-files but will need someone to  
>> take on the c part.
>>
>> If it is desirable and appropriate to reconcile these differences,  
>> I can put together an approach that will allow for incremental  
>> changes that ensures a functional Octave.
>>
>> I'll get started on the sequence of events needed. In the meantime,  
>> I'm eager for feedback so that I'm not wasting effort and/or time.
>>
>> Ben
>
> I thought I'd rename the thread, as we've branched into a new  
> direction.
>
> Regarding a possible sequence of events to resolve these differences  
> between Octave and Matlab, I'd like to propose the following.
>
> (1) Rename the built-in function "pathdef" with to "defaultpath".
>
> (2) Introduce ".../scripts/path/restoredefaultpath.m", which is  
> essentially "path (defaultpath);"
>
> (3) Introduce a new script, named ".../scripts/path/pathdef.m",  
> which returns the path which an octave session begins with, prior to  
> running "~/.octaverc".
>
> (4) The purpose of "savepath" can be left as it is, but might be  
> modified to save the path to "octave-home/share/octave/version/m/ 
> startup/octavrc" when run with admin privilege. In either event, the  
> script should warn the user of which file is modified, when a file  
> is not explicitly specified.
>
> (5) Add script "matlabroot.m" to ".../scripts/path/matlabroot.m" ...  
> perhaps an "octaveroot.m" also/instead?
>
> (6) If it exists in the path, run script "finish.m" upon exiting.
>
> As I have no experience in c/c++ programming, it is likely a bad  
> idea for me to take on (1) or (6), but I'm willing to give (1) a  
> try ... However, if someone is up to posting a patch for (1), I'll  
> incorporate it into my local build and take on the rest.
>
> Ben

Regarding (3), to mock the operation of Matlab as closely as possible,  
it would be preferred that pathdef.m returns the path after startup/ 
octaverc has been run, but before ~/.octaverc (at least thats's the  
way Matlab works on my Mac.

However, there are some problems/features with that. When savepath.m  
is executed, Matlab saves the path to the equivalent of startup/ 
octaverc. At least that is the default ... Since all users on my Mac  
have *write* access to that file, I less than happy about Matlab's  
default.

I'd prefer that Octave (and Matlab for that matter), by default, save  
the path to a file local to the user. In the case of Octave that means  
we could continue to save it to ~/.octaverc. This is relevant to  
pathdef, since it already works that way.

Should we choose to mirror the equivalent of Matlab's default (site  
centric), or continue with octave's default (user centric)?

If we choose to respect Matlab's site centric approach, there still  
remains the problem of accurately mirroring Matlab. In the case, of  
Matlab on my Mac any user my successfully run "savepath". However, in  
the case of Octave, only those with admin access will be successful,  
and since it is rare (and unwise) to run Octave as root, I expect more  
compatibility issues with the site centric option than for the user  
centric option (at least on a Mac).

Thoughts?

Ben