## ``

path variables

-- file search paths

#### Introduction

`LIBPATH` determines the directories, where the functions `loadlib` and `loadproc` search for library files.

`READPATH` determines the directories, where the function `read` searches for files.

`WRITEPATH` determines the directory into which the functions `fopen`, `fprint`, `write`, and `protocol` write files.

#### Call(s)

`LIBPATH := path`
`READPATH := path`
`WRITEPATH := path`

#### Parameters

`path` | - | the path name: a string or a sequence of strings.

#### Related Functions

`fclose`, `finput`, `fopen`, `fprint`, `fread`, `ftextinput`, `loadlib`, `loadproc`, `NOTEBOOKFILE`, `NOTEBOOKPATH`, `package`, `pathname`, `print`, `protocol`, `read`, `READPATH`, `TESTPATH`, `UNIX`, `write`, `WRITEPATH`

#### Details

- `LIBPATH` determines the directories where library files are searched for by the functions `loadproc` and `loadlib`. By default, in the UNIX/Linux version of MuPAD, `LIBPATH` is the subdirectory `$MuPAD_ROOT_PATH/share/lib`. It can be re-defined by calling MuPAD with the command line option `-l`.
- `READPATH` determines the search path for the function `read`. First, `read` searches for a file in the directories given by `READPATH`, then in the ``working directory'', and, finally, in the directories given by `LIBPATH`.
- The variables `LIBPATH` and `READPATH` can represent more than one search directory. These variables can be assigned a sequence of strings: each element of the sequence represents a directory in which files are search for.
- `WRITEPATH` determines the directory, into which the functions `fopen`, `fprint`, `write`, and `protocol` write files which are not specified with a full (absolute) pathname. If `WRITEPATH` is not defined, then the files are written into the ``working directory''.
- Note that the ``working directory'' depends on the operating system. On Windows systems, it is the folder, where MuPAD is installed. On UNIX or Linux systems, the ``working directory'' is the directory where MuPAD was started.

- When concatenated with a file name, the directories given by the path variables must produce valid path names.

- Path names are system dependent. Under UNIX/Linux, a subdirectory is started with a `/`, with `:` on the Macintosh, and with a single backslash `\` on Windows.
- Note that in MuPAD, a single backslash inside a character string is created by two backslashes. E.g., the MuPAD string representing the path ```C:\Programs\MuPAD`'' must be defined by `"C:\\Programs\\MuPAD"`.
- The function `pathname` allows to create path names independent of the current operating system.
- Changing `LIBPATH` is useful for library development. You may create a sub-directory of your home directory with the same structure as the library installation tree and store modified library files there. If you prepend the name of this sub-directory to the variable `LIBPATH` in your startup file `userinit.mu`, then MuPAD first looks for library files in your local directory before searching the system directory. Cf. example 3.

#### Example 1

This example shows how to define a `READPATH`. More than one path may be given. `read` will look for files to be opened in the directories given by `READPATH`. The following produces a valid `READPATH` for UNIX/Linux systems only, since the path separators are hard coded in the strings:

    >> READPATH := "math/lib/", "math/local/"

                            "math/lib/", "math/local/"

It is good programming style to use platform independent path strings. This can be achieved with the function `pathname`:

    >> READPATH := pathname("math", "lib"),
                   pathname("math", "local")

                            "math/lib/", "math/local/"

All path variables can be set to their default values by deleting them:

    >> delete READPATH:

#### Example 2

The path variable `WRITEPATH` only accepts one path string:

    >> WRITEPATH := "math/lib/", "math/local/"

          Error: Illegal argument [WRITEPATH]

#### Example 3

Be careful when changing the `LIBPATH`. You can corrupt your MuPAD session:

    >> LIBPATH := "does/not/exist":
       linalg::det

          Error: can't read file 'LIBFILES/linalg.mu' [loadproc]

You can always restore the standard search path by deleting `LIBPATH`:

    >> delete LIBPATH:
       linalg::det

                            proc linalg::det(A) ... end

Changing the `LIBPATH` is useful for library development. You can build a directory `"mylib"` with the same directory structure as the MuPAD library. Let us assume that you have a patched version of the function `linalg::det` in the file `"mylib/LINALG/det.mu"`. MuPAD will try to read the file `"LINALG/det.mu"` when the function `linalg::det` is called for the first time. Since the directory `"mylib"` contains this file, it will be read instead of the corresponding file in the standard library:

    >> reset():  Pref::verboseRead(2):
       LIBPATH := pathname("mylib"), LIBPATH:
       linalg::det

          loading package 'linalg' [<YourMuPADpath>/share/lib/]
          reading file mylib/LINALG/det.mu

                            proc linalg::det(A) ... end

Please restore your session:

    >> delete LIBPATH:  Pref::verboseRead(0):

#### Changes

- The paths used to be called `LIB_PATH`, `READ_PATH`, `WRITE_PATH`.

Do you have questions or comments?
Copyright © SciFace Software GmbH & Co. KG 2000