Re: path handling

[John Swensen]

John W. Eaton wrote:
> On 11-May-2006, John W. Eaton wrote:
>
> | On 11-May-2006, Søren Hauberg wrote:
> | 
> | | In R, you have to load you packages manually in a similar way. 
> | 
> | | Is it? I'm probably misunderstanding things, as I don't really see the 
> mess.
> | 
> | The mess is that I would like for some things to happen automatically.
> | I don't think that users should not have to explicitly load packages
> | that are installed in a system directory.
> | 
> | Perhaps the simplest solution is to just use genpath on the system
> | directories when Octave starts and then leave everything else to the
> | user.  This approximates what we had before, but explicitly lists the
> | directories in the default path.
>
> OK, I've checked in another largeish change that implements this.
> Here is what I added to the NEWS file:
>
>  ** The way Octave handles search paths has changed.  Instead of
>     setting the built-in variable LOADPATH, you must use addpath,
>     rmpath, or path to manipulate the function search path.  These
>     functions will maintain "." at the head of the path, for
>     compatibility with Matlab.
>
>     Leading, trailing or doubled colons are no longer special.
>     Now, all elements of the search path are explicitly included in
>     the path when Octave starts.  To display the path, use the path
>     function.
>
>     Path elements that end in // are no longer searched recursively.
>     Instead, you may use addpath and the genpath function to add an
>     entire directory tree to the path.  For example,
>
>       addpath (genpath ("~/octave"));
>
>     will add ~/octave and all directories below it to the head of the
>     path.
>
>
> I think path, addpath, rmpath, and genpath should be mostly
> compatible.  If not, I'm sure I'll find out fairly soon...
>
> Now I guess it's time to move on the the guts of the pathsearching
> code and clean that up in preparation for private directories, etc.
>
> jwe
>
>
>
>   
Would you be willing to accept a patch for an additional function that
takes all the directories in the search path and makes a more terse
list?  For example a function called terse_path() would return something
like
[ '.'
  '/home/jswensen/m'
  '/home/jswensen/pkg/m//'
  '/usr/share/octave-2.9.5+/blah//' ]

where the '//' at the end indicates the directories are recursive.  I
just know that if I ever have a deep tree of M files, and want to know
which path comes first in the search path, it can get *really* ugly.

John Swensen