new file mode 100644
--- /dev/null
+++ b/README.kpathsea
@@ -0,0 +1,167 @@
+The code in the files
+
+  liboctave/kpse.h
+  liboctave/kpse.cc
+  liboctave/kpse-xfns.h
+  liboctave/kpse-xfns.cc
+  liboctave/kpse-config.h
+
+was adapted from the kpathsearch library.  We don't use kpathsearch
+directly now because it has too many TeX-specific things that are not
+necessary for Octave, and it also does not implement all the special
+kinds of file searches that Octave needs (mainly for compatibility
+with Matlab).
+
+Original authors of the kpathsearch library
+-------------------------------------------
+
+Karl Berry wrote all files not otherwise marked, with help from Kathryn
+Hargreaves on some of the original versions.
+
+Thomas Esser originated most of the MakeTeX... scripts.
+
+The brace expansion code in expand.c was written by Brian Fox and Chet
+Ramey for Bash, the GNU shell.
+
+The implementation of the link trick in pathsearch.c is taken from GNU
+find, implemented by David MacKenzie from Matthew Farwell's suggestion.
+
+Debugging
+---------
+
+  Kpathsea provides a number of runtime debugging options, detailed
+below by their names and corresponding numeric values.  When the files
+you expect aren't being found, the thing to do is enable these options
+and examine the output.
+
+  You can set these with some runtime argument (e.g., `-d') to the
+program; in that case, you should use the numeric values described in
+the program's documentation (which, for Dvipsk and Xdvik, are different
+than those below).  It's best to give the `-d' (or whatever) option
+first, for maximal output.  Dvipsk and Xdvik have additional
+program-specific debugging options as well.
+
+  You can also set the environment variable `KPATHSEA_DEBUG'; in this
+case, you should use the numbers below.  If you run the program under a
+debugger and set the variable `kpathsea_debug', also use the numbers
+below.
+
+  In any case, by far the simplest value to use is `-1', which will
+turn on all debugging output.  This is usually better than guessing
+which particular values will yield the output you need.
+
+  Debugging output always goes to standard error, so you can redirect it
+easily.  For example, in Bourne-compatible shells:
+     dvips -d -1 ... 2>/tmp/debug
+
+  It is sometimes helpful to run the standalone Kpsewhich utility
+(*note Invoking kpsewhich::.), instead of the original program.
+
+  In any case, you can *not* use the *names* below; you must always use
+somebody's numbers.  (Sorry.)  To set more than one option, just sum
+the corresponding numbers.
+
+`KPSE_DEBUG_STAT (1)'
+     Report `stat'(2) calls. This is useful for verifying that your
+     directory structure is not forcing Kpathsea to do many additional
+     file tests (*note Slow path searching::., and *note Subdirectory
+     expansion::.). If you are using an up-to-date `ls-R' database
+     (*note Filename database::.), this should produce no output unless
+     a nonexistent file that must exist is searched for.
+
+`KPSE_DEBUG_HASH (2)'
+     Report lookups in all hash tables: `ls-R' and `aliases' (*note
+     Filename database::.); font aliases (*note Fontmap::.); and config
+     file values (*note Config files::.).  Useful when expected values
+     are not being found, e.g.., file searches are looking at the disk
+     instead of using `ls-R'.
+
+`KPSE_DEBUG_FOPEN (4)'
+     Report file openings and closings. Especially useful when your
+     system's file table is full, for seeing which files have been
+     opened but never closed. In case you want to set breakpoints in a
+     debugger: this works by redefining `fopen' (`fclose') to be
+     `kpse_fopen_trace' (`kpse_fclose_trace').
+
+`KPSE_DEBUG_PATHS (8)'
+     Report general path information for each file type Kpathsea is
+     asked to search. This is useful when you are trying to track down
+     how a particular path got defined--from `texmf.cnf', `config.ps',
+     an environment variable, the compile-time default, etc.  This is
+     the contents of the `kpse_format_info_type' structure defined in
+     `tex-file.h'.
+
+`KPSE_DEBUG_EXPAND (16)'
+     Report the directory list corresponding to each path element
+     Kpathsea searches. This is only relevant when Kpathsea searches
+     the disk, since `ls-R' searches don't look through directory lists
+     in this way.
+
+`KPSE_DEBUG_SEARCH (32)'
+     Report on each file search: the name of the file searched for, the
+     path searched in, whether or not the file must exist (when drivers
+     search for `cmr10.vf', it need not exist), and whether or not we
+     are collecting all occurrences of the file in the path (as with,
+     e.g., `texmf.cnf' and `texfonts.map'), or just the first (as with
+     most lookups).  This can help you correlate what Kpathsea is doing
+     with what is in your input file.
+
+`KPSE_DEBUG_VARS (64)'
+     Report the value of each variable Kpathsea looks up.  This is
+     useful for verifying that variables do indeed obtain their correct
+     values.
+
+`GSFTOPK_DEBUG (128)'
+     Activates debugging printout specific to `gsftopk' program.
+
+`MAKETEX_DEBUG (512)'
+     If you use the optional `mktex' programs instead of the
+     traditional shell scripts, this will report the name of the site
+     file (`mktex.cnf' by default) which is read, directories created by
+     `mktexdir', the full path of the `ls-R' database built by
+     `mktexlsr', font map searches, `MT_FEATURES' in effect, parameters
+     from `mktexnam', filenames added by `mktexupd', and some
+     subsidiary commands run by the programs.
+
+`MAKETEX_FINE_DEBUG (1024)'
+     When the optional `mktex' programs are used, this will print
+     additional debugging info from functions internal to these
+     programs.
+
+  Debugging output from Kpathsea is always written to standard error,
+and begins with the string `kdebug:'. (Except for hash table buckets,
+which just start with the number, but you can only get that output
+running under a debugger. See comments at the `hash_summary_only'
+variable in `kpathsea/db.c'.)
+
+Logging
+-------
+
+  Kpathsea can record the time and filename found for each successful
+search.  This may be useful in finding good candidates for deletion when
+your filesystem is full, or in discovering usage patterns at your site.
+
+  To do this, define the environment or config file variable
+`TEXMFLOG'.  The value is the name of the file to append the
+information to.  The file is created if it doesn't exist, and appended
+to if it does.
+
+  Each successful search turns into one line in the log file: two words
+separated by a space. The first word is the time of the search, as the
+integer number of seconds since "the epoch", i.e., UTC midnight 1
+January 1970 (more precisely, the result of the `time' system call).
+The second word is the filename.
+
+  For example, after `setenv TEXMFLOG /tmp/log', running Dvips on
+`story.dvi' appends the following lines:
+
+     774455887 /usr/local/share/texmf/dvips/config.ps
+     774455887 /usr/local/share/texmf/dvips/psfonts.map
+     774455888 /usr/local/share/texmf/dvips/texc.pro
+     774455888 /usr/local/share/texmf/fonts/pk/ljfour/public/cm/cmbx10.600pk
+     774455889 /usr/local/share/texmf/fonts/pk/ljfour/public/cm/cmsl10.600pk
+     774455889 /usr/local/share/texmf/fonts/pk/ljfour/public/cm/cmr10.600pk
+     774455889 /usr/local/share/texmf/dvips/texc.pro
+
+Only filenames that are absolute are recorded, to preserve some
+semblance of privacy.