[tex-k] Re: kpathsearch and Octave
John W. Eaton
Fri, 25 Oct 2002 15:12:52 -0500
On 25-Oct-2002, Olaf Weber <firstname.lastname@example.org> 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