pathdef, savepath, ocaverc and Matlab

[Ben Abbott]

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