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

I should have taken a look before send that out. The first item looks  
very simple.

I'll get started.

Ben