[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: path handling
From: |
John Swensen |
Subject: |
Re: path handling |
Date: |
Thu, 11 May 2006 16:14:57 -0600 |
User-agent: |
Thunderbird 1.5.0.2 (Windows/20060308) |
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
- path handling, John W. Eaton, 2006/05/11
- Re: path handling, Søren Hauberg, 2006/05/11
- Re: path handling, John W. Eaton, 2006/05/11
- Re: path handling, Søren Hauberg, 2006/05/11
- Re: path handling, John W. Eaton, 2006/05/11
- Re: path handling,
John Swensen <=
- Re: path handling, Bill Denney, 2006/05/11
- Re: path handling, John W. Eaton, 2006/05/12
- Re: path handling, Keith Goodman, 2006/05/12
- Re: path handling, John W. Eaton, 2006/05/12