I believe Roland and I both understood that a built-in command foo bound to a pathname P would be invoked if P (the path itself) was found on $PATH before the path search found a foo executable on $PATH, and P does not even need to exist for this to work.
But in trying this feature and re-reading some earlier e-mail from David Korn http://www.opensolaris.org/jive/thread.jspa?messageID=29711琏 and the ksh93 manpage, the way it works is that the executable P/foo must exist before the built-in foo bound to pathname P is invoked in ksh93. >From the ksh93 manpage: Execution ... The shell variable PATH defines the search path for the directory containing the command. ... If the command name contains a /, then the search path is not used. Otherwise, each directory in the path is searched for an executable file of the given name that is not a directory. If found, and if the shell determines that there is a built-in version of a command corresponding to a given pathname, this built- in is invoked in the current process. ... So I'm looking for confirmation/clarification that this is actually how this feature is supposed to work. The current plan for initial ksh93 integration in Solaris is to include all 30 of the commands in libcmd as built-ins bound to /usr/ast/bin. On Solaris, this would mean that, in order to invoke the built-in, /usr/ast/bin would need to be on $PATH, *and* the user would need to create /usr/ast/bin containing the like-named executables. If this is the case, it does not make sense to bind these built-ins by default to a non-existent directory. The user can always put in their ~/.profile: builtin -f cmd basename cat chgrp chmod cmp comm cp cut ... to use all the desired AT&T libcmd built-ins and not be concerned about paths and executables. April
