On 3/27/06, April Chin <April.Chin at eng.sun.com> wrote:
>
> > X-Original-To: ksh93-integration-discuss at opensolaris.org
> > Delivered-To: ksh93-integration-discuss at opensolaris.org
> > Date: Mon, 27 Mar 2006 09:58:25 -0500 (EST)
> > From: David Korn <dgk at research.att.com>
> > Mime-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > To: ksh93-integration-discuss at opensolaris.org
> > Subject: Re: Re: [ksh93-integration-discuss] OpenSolaris /usr/bin/ksh
> (builtins)
> > X-BeenThere: ksh93-integration-discuss at opensolaris.org
> > X-Mailman-Version: 2.1.4
> > List-Id: Korn Shell 93 integration/migration project discussion
> <ksh93-integration-discuss.opensolaris.org>
> > List-Unsubscribe:
> <http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss>,
> <mailto:ksh93-integration-discuss-request at
> opensolaris.org?subject=unsubscribe>
> > List-Archive:
> <http://mail.opensolaris.org/pipermail/ksh93-integration-discuss>
> > List-Post: <mailto:ksh93-integration-discuss at opensolaris.org>
> > List-Help:
> <mailto:ksh93-integration-discuss-request at opensolaris.org?subject=help>
> > List-Subscribe:
> <http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss>,
> <mailto:ksh93-integration-discuss-request at
> opensolaris.org?subject=subscribe>
> >
> > >
> > > >> So besides "sleep", the other ksh93 builtins that are not Solaris ksh
> > > >> builtins (and not Solaris binaries) are getconf and printf.
> > > >> Are there dependencies on these being ksh93 builtins?
> > > >>
> > > >> And there are the builtins from libcmd, which are not available
> > > >> by default, but seem to be activated via "builtin <command name>"
> > > >> although I am able to activate only a subset in ksh93:
> > > >>
> > > >> basename
> > > >> cat
> > > >> chmod
> > > >> cmp
> > > >> cut
> > > >> dirname
> > > >> head
> > > >> logname
> > > >> mkdir
> > > >> uname
> > > >> wc
> > > >>
> > > >> Would ksh93 users need to have these builtins available?
> > > >>
> > > >
> > > >printf is needed since it contains extensions that are not
> > > >in the standard printf that are used in several shell scripts.
> > > >
> > > >The ones on this list are provided primarily for performance since
> > > >builtins are 10 to 100 times as fast.
> > >
> > > There are, of course, many issues with the compatibility of the
> > > builtins and the Solaris versions; e.g., chmod has grown a number
> > > of new options relating to ACLs recently.
> > >
> > > In some cases, perhaps, ksh93 could parse the options and when it
> > > decides it doesn't like them fall back to the external command?
> > >
> > > Their remain cases like "uname -a" which probably doesn't much the
> > > builtin.
> > >
> > > And we can also see whether the standard Solaris utilities should grow
> > > additional options to accomodate what ksh93 scripts might expect.
> > >
> > > Casper
> >
> > Builtins in ksh93 can be associated with a directory and when this
> > happens the builtin is only used when the PATH search finds
> > the command in this directory. It would be possible to have a directory
> > named /usr/ast/bin which contained the ast versions of these commands
> > and only users that have /usr/ast/bin before /bin in their PATH would
> > execute these.
>
> 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?
If I understand the issue correctly there are no separate versions of
the ksh93 built in commands - they are just compiled into the shell
and executed as if they were in the specified directory (/bin being
the default if no other value has been specified) once this component
of $PATH is being searched.
> > Another alternative is to extend the ast libcmd versions of these
> > commands to contain all the Solaris extensions.
>
> I wonder if this is a better way to do it, if we are considering
> replacing Solaris versions with AST versions at some point.
If you do it try to keep the extensions portable across operating
systems[1] (following Single Unix Specification v3). If features
specific to Solaris are required then those scripts should address the
Solaris version of those commands explicitly using the full path (a
good example is Solaris patchadd) to prevent the shell built ins being
used.
[1] which means the underlying API should be supported on most of
these operating systems to guarantee that the extended functionality
can be implemented on all of them.
1) A good example of what should NOT be added is the XATTR
functionality recently being discussed as the underlying API is only
available on Solaris.
2) A good example of what should be implemented are the ACL extensions
to chmod(1) as the underlying API is available on almost every decent
flavor of Unix.
--
// Martin Schaffstall
// EMail: martin.schaffstall at googlemail.com
\\ //
\X/
