~/.octaverc overwrites OCTAVE_PATH!!

[Ben Abbott]

On Dec 22, 2008, at 11:15 PM, Ben Abbott wrote:

>
> On Dec 22, 2008, at 5:34 PM, Rosen Diankov wrote:
>
>>
>> 2008/12/22 Ben Abbott <bpabbott at mac.com>:
>>>
>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>
>>>> 2008/12/21 Ben Abbott <bpabbott at mac.com>:
>>>>>
>>>>> On Dec 21, 2008, at 3:38 PM, Rosen Diankov wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm trying to append my own directory with octave files
>>>>>> (/usr/local/myoctavefiles) to the automatically set octave
>>>>>> paths. At
>>>>>> first, I tried doing
>>>>>>
>>>>>> export OCTAVE_PATH=/usr/local/myoctavefiles
>>>>>>
>>>>>> but it didn't work since the auto-generated ~/.octaverc file  
>>>>>> (from
>>>>>> savepath) overwrites any added paths via the path function. Ie,
>>>>>> the
>>>>>> ~/.octaverc file looks like:
>>>>>>
>>>>>> ## Begin savepath auto-created section, do not edit
>>>>>> path ('/usr/local/share/...',...)
>>>>>> ## End savepath auto-created section
>>>>>>
>>>>>> So the next obvious thing to do was to call
>>>>>> addpath('/usr/local/myoctavefiles') right after the '## End
>>>>>> savepath
>>>>>> ...', but this has a very dangerous side-effect. The problem is
>>>>>> that
>>>>>> the next time the user calls 'savepath', it will put
>>>>>> /usr/local/myoctavefiles inside the auto-generated code. And
>>>>>> even if I
>>>>>> remove my addpath or set OCTAVE_PATH to something different, my
>>>>>> path
>>>>>> will remain added to the octave path!
>>>>>>
>>>>>> So I propose a small savepath change that always puts
>>>>>> getenv('OCTAVE_PATH') inside the auto-generated code.
>>>>>> It would be great if this makes it into octave 3.0.4
>>>>>>
>>>>>> thank you,
>>>>>> rosen diankov
>>>>>
>>>>> If I understand you correctly you'd like to be able to
>>>>> dynamically add a
>>>>> specific path when octave is run. Have you looked at the command
>>>>> line
>>>>> options. For example,
>>>>>
>>>>>    octave --path "/usr/local/myoctavefiles"
>>>>>
>>>>> Other command line options are detailed at the link below.
>>>>>
>>>>>
>>>>>
>>>>> http://www.gnu.org/software/octave/doc/interpreter/Command-Line-Options.html#Command-Line-Options
>>>>>
>>>>> Ben
>>>
>>>>
>>>> It doesn't work, the ~/.octaverc file overwrites any paths from
>>>> OCTAVE_PATH, -p, or --path because savepath directly calls path. it
>>>> would be great if at least it called addpath.
>>>>
>>>> rosen,
>>>
>>> Do you mean you'd like to have the lines added to .octaverc by
>>> savepath use
>>> "addpath(...)" rather than "path(...)"?
>>>
>>> sigh ... I find the savepath command more trouble that it is
>>> worth :-(
>>>
>>> You may find the best solution it to modify .octaverc by manually
>>> and use
>>> addpath() to include your local octave directories.
>>>
>>> In any event, we will want to be compatible with matlab. Does
>>> matlab provide
>>> the functionality you're looking for?
>>>
>>> Ben
>>>
>>
>> I agree with you. the current savepath does break some things about
>> the flow of paths in octave. We recently started using octave for a
>> robotics framework ROS
>> (http://pr.willowgarage.com/wiki/rosoct#preview) and we are starting
>> to create many packages that optionally have octave code that use a
>> core ROS 'octave library'. In order for those functions to be visible
>> in octave, they have to be added to the path, so I would like the
>> users to be able to add a simple
>>
>> export OCTAVE_PATH=...
>>
>> in their .bashrc that automatically finds the correct directory and
>> includes it. The path will be dependent on the particular directory
>> their checkout tree lies in (which can change).
>>
>> The problem with savepath is that it sucks in the current paths into
>> its one 'path' call, which makes using multiple build trees of the
>> robotics framework very hard.
>>
>> According to the matlab savepath, there is a separate 'userpath'
>> variable that gets combined with the current paths.
>>
>> Ideally, savepath would remove all directories in OCTAVE_PATH before
>> making the addpath call (there's no reason it should be calling  
>> path).
>>
>> thanks,
>> rosen,
>
> A proper fix will be slightly more a bit more difficult than patching
> savepath.m. In addition to OCTAVE_PATH a proper solution should also
> treat the command line path option in the same fashion. My c/c++
> skills are essentially non-existent, but this looks like a simple task
> (maybe even I can manage it).
>
> What is needed it to make the "tpath" in load_path::do_initialize  of
> load-path.cc were available to m-files.
>
> ----------------------
>   std::string tpath = load_path::command_line_path;
>
>   if (tpath.empty ())
>     tpath = octave_env::getenv ("OCTAVE_PATH");
> ----------------------
>
> Can anyone tell me if such is *already* available to m-files. I'd
> tried adding the code below to load-path.cc, but it doesn't work ...
> which I expect demonstrates my c/c++ incompetence ;-)
>
> ----------------------
> DEFUN (commandlinepath, , ,
>     "-*- texinfo -*-\n\
> @deftypefn {Built-in Function} {} commandlinepath (@dots{})\n\
> Return the command line path variable.\n\
> \n\
> @seealso{path, addpath, rmpath, genpath, pathdef, savepath, pathsep} 
> \n\
> @end deftypefn")
> {
>   return octave_value (load_path::command_line_path);
> }
> ----------------------
>
> Can someone enlighten me as to what I'm doing wrong? ... a "make" from
> the src directory produces the result below.
>
> ----------------------
> $ make
> making defaults.h from defaults.h.in
> defaults.h is unchanged
> make: --cppflags: Command not found
> make: --ldflags: Command not found
> making oct-conf.h from oct-conf.h.in
> oct-conf.h is unchanged
> g++ -c -g -I/sw/include -FOpenGL -I/sw/include/freetype2 -I/sw/include
> -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -
> DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2
> load-path.cc -o pic/load-path.o
> load-path.cc: In function ‘octave_value_list Fcommandlinepath(const
> octave_value_list&, int)’:
> load-path.cc:48: error: ‘std::string load_path::command_line_path’ is
> private
> load-path.cc:1783: error: within this context
> make: *** [pic/load-path.o] Error 1
> ----------------------
>
> Ben

No need for anyone to point out what I missed. I noticed the public/ 
private declarations in load-path.h.

However, it occurred to me that using addpath() in place of path() is  
not ensured to preserve the order of the path definition.

I'm moving this thread to the developers list (which I should have  
done earlier).

I'll make an attempt at implementing the desired change and produce a  
changeset for the developers sources.

Ben