[tex-k] Re: kpathsearch and Octave

[John W. Eaton]

On 25-Oct-2002, Olaf Weber <olaf@infovore.xs4all.nl> wrote:

| That's because there is no such code at present.
| 
| > Suppose there are two directories /foo and /bar that contain the same
| > file X.  Then if the user starts out with /foo in the path and looks
| > up X, they will find /foo/X, and that's fine.  Now they change the
| > path to /bar, and they should find /bar/X.  Is that what will happen?
| 
| Yes -- when you look for 'X', entries for /foo/X and /bar/X are both
| found in the hash table, and then matched to the given path.  Only if
| it is actually on the search path will the entry be returned.  The
| code relies on this in several ways -- for example, a few duplicate
| entries tend to be present in the default texmf tree, and therefore
| also in the database that is built from the ls-R.  We use different
| search paths to ensure that we find one entry instead of another.
| 
| > What about if /foo/X exists and the user simply removes /foo from the
| > path?  Does it remain in the cache, so it will still be found, even
| > though the user has removed /foo from the path?
| 
| The /foo/X entry is still in the database, but if someone searches for
| X along path that doesn't include /foo, it will not be found.

OK.  I removed the call to my kpse_clear_dir_cache function from
Octave and it still behaves correctly, so I don't think it is needed.
Now, I wonder why I ever thought that it would be?!

| By the way, this reminder of yours did come at a good moment, as we
| haven't quite frozen the code for the next web2c yet.

OK.  If the memory leak fix goes in before the next release, then I
think we (Octave) can start using unmodified sources for the libarary
soon.

Thanks,

jwe