Re: ~/.octaverc overwrites OCTAVE_PATH!!

[Rosen Diankov]

sorry, separate it with commas:

path(path,'/my/other/paths','asdfas')

rosen,

2008/12/23 Rosen Diankov <address@hidden>:
> To preserve path order, you can have savepath do:
>
> path(path,'/my/other/paths:asdfas')
>
> i would do the necessary changes, but i'm not sure where the savepath code is.
>
> rosen,
>
>
> 2008/12/23 Ben Abbott <address@hidden>:
>>
>> 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 <address@hidden>:
>>>>>
>>>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>>>
>>>>>> 2008/12/21 Ben Abbott <address@hidden>:
>>>>>>>
>>>>>>> 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
>>
>>
>