On 3/27/06, April Chin <April.Chin at eng.sun.com> wrote:
> Okay, I finally think I understand how this works...
> when I initially tried using the builtins for cat, chmod, etc. in ksh93
> I did not have /bin on my PATH (only /usr/bin), so /bin/cat was
> not the first cat found on the PATH and the builtin cat was not executed.
> The builtins bound to /bin in ksh93
> (basename, cat, chmod, cmp, cut, dirname, head, logname, mkdir,
> uname, & wc) are available by default if the /bin/cat executable, for example,
> is first found on PATH (as you stated).
>
> I think you are saying we could bind these executables to /usr/ast/bin
> instead of /bin. Is /usr/ast/bin where users might typically install
> the AST versions of the executables? Or would this mean that Solaris
> should provide the binary versions in /usr/ast/bin?
There is another way to bind built-ins to pathnames. When ksh
process the PATH variable it looks for a file named .paths
in the directory. If it is found, then it reads this file
looking for the following:
LD_LIBRARY_PATH=dir
If a binary is found in this directory, the dir is prepended
to LD_LIBRARY_PATH. A relative directory is relative to
this directory. (The name LD_LIBRARY_PATH might be something
else on systems that use a different name for shared library
searching.) This, if dir is ../lib, then shared libraries
found in the cousin directory will be found.
BUILTIN_LIB=name
Any commands implemented in the library named by name will
be run as builtins after loading the library. Thus, if
libcmd is in /usr/ast/lib and
BUILTIN_LIB=cmd
is in .paths, then all the libcmd builtins will be builtin
when this directory is searched.
FPATH=dir
If the command being searched is not found in this directory
then <dir> will be searched for functions before the next
path in PATH. If found the file will be sourced and a function
by the specified name will be executed. This allows any
command to be written as a shell function.
David Korn
dgk at research.att.com
