Chapter 4. Basic Shell Programming

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:

1. 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.

2. In your .profile file, add this directory to both the variables PATH and FPATH:

   PATH=$PATH:~/funcs
   FPATH=~/funcs
   export PATH FPATH
   

3. 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!)

Readers familiar with ksh88 will notice that this part of the shell's behavior has changed significantly. Since ksh88 always read the environment file, whether or not the shell was interactive, it was simplest to just put function definitions there. However, this could still yield a large, unwieldy file. To get around this, you could create files in one or more directories listed in $FPATH. Then, in the environment file, you would mark the functions as being autoloaded:

autoload whoson
...

ksh93's integration of PATH and FPATH searching thus simplifies the way you add shell functions to your personal shell function "library."

4.1.1.2. POSIX functions

As mentioned earlier, functions defined using the POSIX syntax obey POSIX semantics and not Korn shell semantics:

functname () {
    shell commands
}

The best way to understand this is to think of a POSIX function as being like a dot script. Actions within the body of the function affect all the state of the current script. In contrast, Korn shell functions have much less shared state with the parent shell, although they are not identical to totally separate scripts.

If you use the dot command with the name of a Korn shell function, that function will obey POSIX semantics, affecting all the state (variables and traps) of the parent shell:

$ function demo {                          Define a Korn shell function
>   typeset myvar=3                        Set a local variable myvar
>   print "demo: myvar is $myvar"
> }
$ myvar=4                                  Set the global myvar
$ demo ; print "global: myvar is $myvar"   Run the function
demo: myvar is 3
global: myvar is 4
$ . demo                                   Run with POSIX semantics
demo: myvar is 3
$ print "global: myvar is $myvar"          See the results
global: myvar is 3