> From: Mike Kupfer <mike.kupfer at sun.com>
> To: April Chin <April.Chin at eng.sun.com>, Korn Shell 93
> integration/migration
project discussion <ksh93-integration-discuss at opensolaris.org>
> Subject: Re: [ksh93-integration-discuss] getconf
> Date: Thu, 05 Oct 2006 16:49:32 -0700
>
> >>>>> "April" == April Chin <April.Chin at eng.sun.com> writes:
>
> April> The built-in behavior *may* depend on $PATH, if that built-in is
> April> bound to a pathname. [...] In the default ksh93, getconf is a
> April> standalone built-in, not bound to a path
>
> Ah, I see. What determines whether a built-in is bound to a pathname?
> (Put another way: why are some built-ins bound and others, like getconf,
> not bound?)
The unbound built-ins (e.g., printf, echo) and those bound to /bin
(cat, chown, head, mkdir, rmdir, tee, uniq, wc ) were determined to be
compatible with the corresponding Solaris /usr/bin utilities.
Note that in Solaris ksh, there are no such built-ins.
So a ksh93 user in the Solaris OS would see compatible behavior executing
"cat" (no pathname prefix, but presumably with the usual /bin or /usr/bin
on their path) as they would in Solaris /usr/bin/ksh.
The built-ins which are incompatible are bound to the /usr/ast/bin
pathname only. The /bin-bound pathnames are also bound to /usr/ast/bin.
A ksh93 user invokes these built-ins by putting /usr/ast/bin in the
beginning of their path.
Previously, I believe all built-ins were unbound. In ksh93, built-ins were
added for the utilities, for increased performance.
Binding the utility built-in to the /bin pathname allowed them to only
be run if the compatible utility in /bin would have been invoked.
In an AT&T environment the /bin utility would be exactly
the same as the built-in. In the Solaris environment, we need to make
sure the built-in is upwardly compatible with the Solaris /bin utility
before enabling it by default in ksh93.
April
April
>
> mike
