[ksh93-integration-discuss] built-ins bound to /usr/ast/bin

[April Chin]

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&#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