[changeset] ~/.octaverc overwrites OCTAVE_PATH!!

[Ben Abbott]

On Dec 24, 2008, at 1:17 PM, John W. Eaton wrote:

> On 24-Dec-2008, Ben Abbott wrote:
>
> | 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.
>
> If some elements were added before and some after the default path,
> wouldn't it be possible to determine that when parsing the path, and
> then use addpath to append/prepend as necessary?

Yes, I think that is a better strategy. However, as It is possible  
that some path element are also placed inside the elements of  
pathdef() (by a mischievous user perhaps?). How might that be handled?

I can check to see if user specified elements (1) precede the the 1st  
element in pathdef(), (2) follow the last element of pathdef(), or (3)  
precede the entire pathdef() block. I'll assume that either (1) or (2)  
would be preferred. I'll implement (1) as it looks like the more  
obvious choice (to me).

> | +function [ subpaths ] = parsepath (p)
>
> There is no need for the [] if there is only one return value, so
> please write
>
>  function subpaths = parsepath (p)
>
> instead.
>
> | +  pat = '([^:]+[:$])';
> | +  [S, E, TE, subpaths] = regexpi(strcat (p, ':'), '([^:]+[$:])');
> | +endfunction
>
> To avoid confusion with the transpose operator, please use " to
> delimit strings.  Also, for consistency with the rest of Octave,
> please avoid upper-case variable names.

ok, done!

> | diff -r 654bcfb937bf -r 8f389284c849 src/load-path.h
> | --- a/src/load-path.h	Tue Dec 23 08:28:23 2008 +0100
> | +++ b/src/load-path.h	Tue Dec 23 17:09:25 2008 -0500
> | @@ -218,6 +218,8 @@
> |        command_line_path += dir_path::path_sep_str () + p;
> |    }
> |
> | +  static std::string command_line_path;
> | +
>
> Instead of making this public, which will allow users to modify it,
> please create a static function that returns the value instead.  Then
> the value will still be protected from having users change it.

ah-ha ... it didn't occur to me that I'd made command_line_path  
writable. My intent was to permit is value to be passed on the an m- 
file. I'll take another look.

Ben