> The whole concept of builtins being bound to a pathname is fairly new to me,
> and it may be new for others. Or maybe I was just ignorant. :-)
> Do other shells have this construct?
> It may not be as much of an issue for a separate /usr/bin/ksh93
> as it would be for ksh93 as /usr/bin/ksh.
>
>
I don't know of any shells that have this feature. I introduced it
in ksh93. I will describe ksh93 specific features related to
command search below.
When System III was introduced in the early 80s, test and echo
were made buit-in commands to improve performance. At the
time it broke several scripts because users had their own
commands with these names and theirs had bee first in the PATH.
For commands of short duration, a built-in typically runs about
50 times as fast as a non-builtin version. In addition,
the number of arguments to built-ins is not bounded by ARG_MAX.
I decided that it should be possible to make any command a built-in
without affecting anything other than performance and that the
way to do this was to equate the builtin with the executable.
Thus, if the user does
builtin /bin/date
and the shell has a function b_date, it will execute this
function whenever it would have done a PATH search and would
have executed /bin/date. Note that an explicity pathname in
the script will not cause b_date to execute. (The assumption is
that scripts that want performance should not put explicit
pathnames for commands.)
Now, since we wrote libcmd and it contained many versions of standard
commands, we decided to initialize these to be equivalent to the
version in /bin for performance reasons. This set can be adjusted
at runtime. The goal is to boost performance without affecting users.
If they are not compatible, then they should either not be used or
they should be made compatible.
At one of the point releases for ksh93, we added another feature
that allows a specification in the directory to specify to use
builtins whenever possible for all binaries in that directory.
Any directory on the PATH can have a file named .paths. The .paths
file can contain an entry such as
BUILTIN_LIB=cmd
which will cause builtins stored in the cmd library to be used
whenver that command would be found in this directory. Thus, for
the AST bin directory, this causes commands in libcmd to be used
rather than the ones in this directory.
The .paths file has to other purposes. It allows a function directory
to be specified. After searhing this directory, and before
searching the next directory in the PATH, the function directory
is searched, and if found there the file is loaded and then a
command of that name is executed. For example,
FPATH=../fun
causes functions from $PWD/../fun to be used. Since
pushd, popd, and dirs are implemented as ksh functions,
this can be invoked without first loading the functions
into the shell.
The other use for the .paths file is to specify a library path
variable that will get inserted whenver a command in this
directory is executed. For example,
LD_LIBRARY_PATH=../lib
causes $PWD/../lib to get inserted at the fron to LD_LIBRARY_PATH
when running a command in this directory. This way, a user
that wants to use commands in /usr/ast/bin, just need to add
/usr/ast/bin to their PATH and they don't need to add /usr/ast/lib
to their LD_LIBRARY_PATH.
David Korn
dgk at research.att.com
