Re: octaverc and version in path?

[Ben Abbott]

On Dec 29, 2007, at 10:21 AM, Ben Abbott wrote:

On Dec 29, 2007, at 9:52 AM, Daniel J Sebald wrote:

Ben Abbott wrote:

This inclusion of the path presents some problems. For example,  the .octaverc is not upgraded when octave is, and produces a conflict  in the event a user wants to install different versions of octave.

I assume the version information is there for a reason, what is that  reason?

Might something be done regarding how the path is handled to  facilitate the upgrade process, and perhaps allow for installations of  multiple versions?

OCTAVE_VERSION has been around fairly long.  Could one test that variable inside .octaverc?

Dan

Yes such a test would work.  However, the creation and automatic maintenance of .octaverc might get messy. Especially since users will commonly edit it.

In any event, some options are

(1) Modify savepath.m to create a .octaverc to support different versions of octave.

(2) Modify savepath.m/.octaverc to remove the references to the version number.

(3) Remove all path information respecting octave's core functions/oct-files from .octaverc and load the default each time as done when no .octaverc exists.

Those are off the top of my head.

Anyone have thoughts as to the "big picture" pros/cons of these options?

An example of how (3) might be implemented is to modify savepath.m in order to produce an .octaverc like that below.

## Begin savepath auto-created section, do not edit

  path ([pathdef,pathsep,'/Users/bpabbott']);

## End savepath auto-created section

The version specific path is implicitly handled by "pathdef" and the localized portion is explicitly added to the end.

This means that the '-begin' and '-end' options of addpath may be muddled by the savepath when octave is restarted. 

It might also be useful to check the path at startup to verify each directory in the path actually exists. If not a warning can be given and it non-existent directory can be pruned from the working path.

Thoughts?

Ben