Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

[Rosen Diankov]

Hi Ben,

great work!

As for the ordering issue, I would argue that if any user is advanced
enough to care about ordering, they will save the path history
themselves and not rely on savepath. Calling addpath is much cleaner
now since user and system paths have a smaller chance of getting mixed
up.

rosen,

2008/12/24 Ben Abbott <address@hidden>:
>
> On Dec 23, 2008, at 10:17 PM, Ben Abbott wrote:
>>
>> <snip>
>
> This changeset is intended to avoid having the path statement in octaverc
> (generated by savepath.m) over-write the paths originating from the
> environment and/or from the command line, the next time octave is run.
>
> This is done by
>
> (1) Having savepath.m place an addpath(...) rather than path(...) statement
> in octaverc.
>
> (2) Removing the command-line & environment paths from the working path
> prior to writing the addpath statement to octaverc. In the event that
> pathdef() is empty, only the path from the environment is removed from the
> working path (which is assumed to be generated via the procedure used by
> run-octave)
>
> (3) As knowledge of the command_line_path was needed by savepath.m,
> load-path.cc and load-path.h were modified to add the new function
> commandlinepath().
>
> It may also be desired to remove the path associated with pathdef() from the
> working path prior to writing the addpath statement to octaverc.
>
> By doing so only the portion added by the user should remain. This would
> also make upgrading from one version of octave to another more convenient
> (on my Mac the path to the core functions includes the version number). This
> would be my personal preference.
>
> However, this will make it much more likely that the ordering of the path
> will not be preserved for subsequent executions of octave. Meaning that the
> user specified portions would either be added at the beginning or the end,
> but would not show up both ways.
>
> As that may be a relatively significant compatibility issue, the path
> associated with pathdef() is still saved to octaverc.
>
> My local octave package I had been using to install a working copy of octave
> build from mercurial broke rather recently. I've not yet been able to
> resolve the problem. Thus, I'm presently running a fresh build with these
> changes via run-octave.
>
>  Ben
>
>
>
>
>
>