4.1.1.1. Automatically loading functions
At first glance, it would seem that the best place to put
your own function definitions is in your .profile
or environment file.
This is great for interactive use, since your login shell reads
~/.profile, and other interactive shells
read the environment file. However, any shell scripts that you
write don't read either file.
Furthermore, as your collection of functions grows, so too
do your initialization files, making them hard to work with.
ksh93 works around both of these issues by integrating the
search for functions with the search for commands.
Here's how it works:
Create a directory to hold your function definitions.
This can be your private bin directory, or
you may wish to have a separate directory, such as ~/funcs.
For the sake of discussion, assume the latter.
In your .profile file, add this directory
to both the variables PATH
and FPATH:
PATH=$PATH:~/funcs
FPATH=~/funcs
export PATH FPATH
In ~/funcs,
place the definition of each of your functions into a
separate file. Each function's file should have the same
name as the function:
$ mkdir ~/funcs
$ cd ~/funcs
$ cat > whoson
# whoson --- create a sorted list of logged-on users
function whoson {
who | awk '{ print $1 }' | sort -u
}
^D
Now, the first time you type whoson, the shell looks
for a command named whoson using the search order
described earlier. It will not be found as a special-built-in, as a function,
or as a regular built-in.
The shell then starts a search along $PATH.
When it finally finds ~/funcs/whoson, the shell
notices that ~/funcs is also in $FPATH.
("Aha!" says the shell.)
When this is the case, the shell expects to find the definition of
the function named whoson inside the file.
It reads and executes the entire contents of the file and only
then runs the function whoson, with any supplied
arguments.
(If the file found in both $PATH and $FPATH
doesn't actually define the function, you'll get a "not found" error
message.)
The next time you type whoson, the function is
already defined, so the shell finds it immediately, without the need
for the path search.
Note that directories listed in FPATH but not in
PATH won't be searched for functions, and that as
of ksh93l,
the current directory must be listed in FPATH via an explicit dot;
a leading or trailing colon doesn't cause the current directory
to be searched.
As a final wrinkle, starting with ksh93m,
each directory named in PATH may contain a file
named .paths.
This file may contain comments and blank lines, and specialized variable assignments.
The first allowed assignment is to FPATH, where the value should
name an existing directory. If that directory contains a file whose name
matches the function being searched for, that file is read and executed
as if via the . (dot) command, and then the function
is executed.
In addition, one other environment variable may be assigned to.
The intended use of this is to specify a relative or absolute path
for a library directory containing the shared libraries for executables
in the current bin directory.
On many Unix systems, this variable is LD_LIBRARY_PATH,
but some systems have a different variable -- check your local documentation.
The given value is prepended to the existing value of the variable
when the command is executed.
(This mechanism may open security holes. System administrators
should use it with caution!)